Original Content (Japanese) : http://level69.net/archives/26130
Introduction
The App Service Environment is a way to deploy App Service within a virtual network.
There are two types.
1, External ASE: Externally accessible
2, ILB ASE (This name for installing internal load balancer): External access impossible
So why do you recommend it?
1, managed service
2, scaling
3, load balancing and SSL termination
4, security (WAF)
Can also be realized with App Service + Application Gateway.
However, it is possible to avoid Application Gateway as follows. It is meaningless if it is avoided even if WAF is put.
In other words, it is not recommended from the viewpoint of security too much.
Then what should we do?
The feature that appears there is App Service Environment.
The above ILB ASE can be combined with Application Gateway to restrict external access and add WAF functions.
If you create it with external ASE, it will not be possible to restrict access from outside, so it will not be meaningful simply because App Service is created inside the virtual network.
Using ILB ASE, you can perform load balancing, SSL termination, security (WAF).
In addition, it is considered that using managed services makes operation easier.
I think that atmosphere is analogous to deploying AWS Elastic Beanstalk in VPC.
I think that it is the composition of VPC + Beanstalk + ALB + AWS WAF.
ILB ASE is created by the following procedure.
1, Create an App Service Environment
2, Create an App Service
3, Create Application Gateway
Create App Service Environment
First we will create an App Service Environment.
The essential point is to create the side. It is like a box to put App Service.
Click on Web → App Service Environment from Create a resource.
Enter the necessary items.
Click Virtual Network and change the VIP Type to Inernal.
For Domain, enter the domain to use for App Service.
It takes about 1 hour to create.
I will wait for a while.
After creation, register the certificate in the ILB.
* .your-root-domain-here and *. scm.your-root-domain-here must be created in one certificate.
When using a self certificate
$certificate = New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -dnsname "*.internal-contoso.com","*.scm.internal-contoso.com"
$certThumbprint = "cert:\localMachine\my\" +$certificate.Thumbprint
$password = ConvertTo-SecureString -String "CHANGETHISPASSWORD" -Force -AsPlainText
$fileName = "exportedcert.pfx"
Export-PfxCertificate -cert $certThumbprint -FilePath $fileName -Password $passwordWhen using Let’s Encrypt
You can create it using v2.
You can easily create with the browser on the following site.
FreeSSL.org
Https://freessl.cn/
Enter domains separated by “,”. Select v2.
Enter your email address and create it.
First, private key is entered.
Set the TXT record in DNS and check the owner.
登録確認が終わったらダウンロードします。
In addition, it must be in pfx format for registration.
openssl pkcs12 -export -inkey private.pem -in full_chain.pem -out server.pfx
Enter Export Password:
Verifying - Enter Export Password:Password is required
Register the created pfx.
You can confirm that it was registered.
Creation of the App Service Environment is complete.
Now that we have a box, we will deploy App Service next.
Create App Service
I will create a Web App in the usual procedure, but first create a service plan.
The ASE you created will be displayed in the Location selection of the service plan.
When creating a service plan, the domain of Web App will be changed to that specified by you.
For OS and Publish, select the ones that are appropriate for the required environment.
The following configuration was created with the above.
In order to check the configuration, there is only a method of creating a VM in VNET and checking it from within VNET.
Launch Virtual Machine. Launch Windows 10 to check with the browser.
However, since it can not be created in the subnet using ASE, create a subnet appropriately and launch Virtual Machine.
Log in to the virtual machine you started up.
Next, set the IP in the hosts file as shown below.
192.168.250.11 envdemo-webapp.shinagawa.cloud
192.168.250.11 envdemo-webapp.scm.shinagawa.cloudIP becomes internal load balancer IP address of ASE.
Alternatively, you can check on the custom domain of App Service.
Of course, because it is a private address, it can not be accessed from the outside, but it can be confirmed from inside.
You can confirm that you can access with the domain you set up.
Also check that you can log in with kudu.
You will be asked for your user name and password.
The user name and password are written in the publish profile.
Check the contents of the downloaded file.
UserName (including $) and userPWD.
Confirm that it is displayed.
That’s all there is to confirm.
Next, create an Application Gateway to access from the outside.
Create Application Gateway
Create the Application Gateway in the usual way.
However, I will add a dedicated subnet in advance.
Enter the item.
Specify the VNET and subnet created above.
We will also activate WAF.
I will wait for a while.
After creation, set up the backend pool.
Specify the IP of the load balancer.
Configure the probe.
Set up the domain specified by ASE.
Configure HTTP.
Set up a custom probe.
Check backend for any problems.
Configure the domain.
Specify the public IP set for Web App in the custom domain with CNAME.
Specify it to DNS for testing.
You can confirm that you can connect with HTTP.
In order to connect with HTTPS, add a Listener.
Make sure you can access it.
To set up another domain, set it as a custom domain and then set up the Listener.
The above configuration is completed with the above.
Summary
I explained how to deploy Web App in virtual network by using App Service Environment.
You can improve security by publishing only to Application Gateway outside.
In addition, it is also possible to completely operate on a private network by connecting ExpressRoute or VPN.
Therefore, I think that it is best for the environment of the enterprise.
