NGINXaaS for Azure: Azure Key Vault
Welcome back to our series on F5 NGINXaaS for Azure! Last time we set up basic load balancing using NGINXaaS for Azure. Today, we’re going to look at using Azure Key Vault to manage the keys for TLS offloading. Azure Key Vault Much like how NGINXaaS for Azure takes care of managing the underlying infrastructure to run NGINX Plus instances, Azure Key Vault manages key storage, including secure Hardware Security Modules (HSMs), to keep sensitive cryptographic material secure and away from prying eyes. NGINXaaS for Azure integrates with Azure Key Vault to manage your TLS keys in a secure manner. Getting Started We’ll pick up where we left off from our previous article; we’ve configured an NGINXaaS for Azure instance, and we have it load balancing to a pool of backend servers. Creating a Managed Identity To use Azure Key Vault, we need to be able to authorize our NGINX instance access the appropriate key material. We do this with a Managed Identity (MI). To create the identity: Search for “Managed Identities” in the top search bar Click “Create” Select a resource group and region for the identity Give the identity a name Click “Review and Create”, then “Create” We then need to ensure that our MI has the correct permissions to use the vault. Our vault uses Access Policies rather than RBAC, so our process is: Open the key vault and select “Access Policies” from the left-hand menu Click “Create” Select the “GET” Secrets permission and click “Next” Select the Managed Identity for our NGINX instance as the Principal Click through to finish creating the Access Policy If you are using RBAC, the process is similar but you need give your MI the “Key Vault Secrets User” or higher role in the vault’s IAM menu. Configure NGINX Now that we have our vault access set up, we can assign our Managed Identity to our NGINX instance and use a certificate from that vault in our NGINX config. Like last time, I won’t be screenshotting every click, but full documentation is available at the official NGINX docs. From your NGINX instance, click “Identity” from the left-hand menu Click “Add Select the Managed Identity, and click “Add” Now to configure the certificate: Click “NGINX Certificates” from the left-hand menu Click “Add Certificate” Give the certificate a name Specify the path to where your NGINX config will find the certificate and key Select the key vault and certificate that you wish to use Click “Save” From here it’s just like configuring TLS offload on any NGINX instance. Listen on 443, and specify the ssl_certificate and ssl_certificate_key paths we created above. Now let’s test it out: I got the red lock here because I used a self-signed certificate, but the fingerprint matches what’s in Azure Key Vault. Summary While we could have just uploaded our certificate and key with the configuration set, that archive would then contain sensitive key material, and needs to be protected. Using NGINXaaS for Azure with Azure Key Vault provides a secure way to manage your TLS secrets. Stay tuned to learn more advanced features of NGINXaaS for Azure. References DevCentral Series - F5 NGINXaaS for Azure NGINXaaS for Azure Marketplace Listing NGINXaaS for Azure Docs Azure Key VaultNGINXaaS for Azure: Load Balancing
NGINXaaS for Azure dramatically simplifies deploying NGINX Plus instances into your Azure environment. Gone are the days of managing your own compute or container instances; now you can deploy NGINX Plus right from the Azure console or CLI and upload your nginx.conf directly. In this article, we’ll take a look at deploying one of the most common use cases: load balancing to a set of backend resources. Getting Started If you haven’t read Jeff Giroux’s excellent article on getting started with NGINXaaS for Azure (which I highly recommend doing), we’ll quickly go through the process of getting a new instance deployed and running. I won’t be going through every step in detail, feel free to check out Jeff’s article or the official documentation. Searching for “NGINXaaS for Azure” in the Azure Marketplace brings up the NGINXaaS offering: Once we subscribe to this offer, there’s not much to configure. We can create a new vnet or select an existing one, decide whether we want to assign a public IP, and assign any tags. Keep in mind that NGINX Plus doesn't actually live inside this subnet. NGINXaaS uses new Azure networking capabilities to keep end-user traffic private. Each NGINX Plus instance passes traffic to downstream services via an elastic network card (NIC) that exists inside your subscription. These NICs are injected into a delegated virtual network. A network security group controls traffic to your NGINX Plus instances. After we review and click “create”, and with just a few more clicks we have our instance available! A Network Security Group was created as part of the deployment, so we just need to allow ports 80 and 443, and we’re ready to start passing traffic. Browsing to the public IP of the NGINX instance should bring up a Hello World page. Configuration Configuration for your NGINX instance is available from the left-hand menu. One of the big benefits of using NGINXaaS for Azure is that it takes the same nginx.conf file format that you’re already used to. You can paste your config right into a new file here like I’ve done, or you can upload a gzipped archive with your full configuration set. Again, more details are available in the docs. If you’ve ever front-ended web or app servers with NGINX before, this part should look pretty familiar; we’re configuring an upstream with a few backend servers (running as Azure Container Instances), with a proxy_pass pointing to that upstream. Click “Submit”, and there we have it: a working NGINX Plus load balancer. No TLS yet, I’ll be covering that in the next article in this series that covers Azure Key Vault. We can also configure additional NGINX features, like health checks, basic caching and rate limiting, by adding the appropriate configuration: Note that although NGINXaaS for Azure scales instances as necessary, they aren’t currently configured as a cluster, so there are a few limitations with features like caching and rate limiting. More details are available in the official docs. Summary With just a few clicks, and no VMs or containers to manage (not including the backends), we have a full NGINX Plus instance up and running and passing traffic. Start to finish, the process only took a few minutes. If you want to see how we can add more functionality to this instance, stay tuned for net next article in this series, where we’ll show you how to use Azure Key Vault to manage TLS certificates with NGINXaaS for Azure. References DevCentral Series - F5 NGINXaaS for Azure NGINXaaS for Azure Marketplace Listing NGINXaaS for Azure DocsPublic Cloud Simplified with F5 NGINXaaS for Azure
The teams at F5 and Microsoft have partnered to jointly develop a new native offering known asF5 NGINXaaS for Azure. The NGINXaaS offering is a simple and secure way to help you migrate and extend application workloads from on-premises to the Azure public cloud by bringing your configurations. If you are using NGINX today, or planning to use it in the future but are not quite sure where to start, then continue reading to learn more about the following: Overview of F5 NGINXaaS for Azure F5 NGINXaaS for Azure is built directly into the Azure portal and is tightly integrated with the Azure ecosystem. This means you can utilize Azure security services like Azure Key Vaultfor bringing your SSL/TLS certificates and keys while using Azure Monitorfor NGINX deployment metrics. You can even manage your NGINX configuration with syntax validation…all in one Azure panel. Of course, you can use your preferred method to deploy and manage: the Azure Portal, API or CLI. Talk about ease of use! Here is a high-level architecture of F5 NGINXaaS for Azure and the related Azure components. Key capabilities powered by F5 NGINXaaS for Azure: Simplifies onboarding by leveraging NGINX as a service Lowers operational overhead in running and optimizing NGINX Supports migration of existing NGINX configurations to cloud with minimal effort Azure ecosystem integration (Azure Key Vault, Azure Monitor, Azure AD) Addresses wide range of deployment scenarios (HTTP reverse proxy, JWT authentication, etc) Consumption-based pricing For the complete set of capabilities of this offer, refer to the F5 NGINXaaS for Azure docs. Problems Solved by F5 NGINXaaS for Azure F5 NGINXaaS for Azure removes the burden of having to deploy your own NGINX Plus cluster, install libraries, upgrade, and manage it. Whether you are an existing or new NGINX customer, this means speed and simplicity with no IaaS to manage. This ease of use means there is no need for expert knowledge, and this is especially compelling for customers new to NGINX. If you are an existing NGINX customer, F5 NGINXaaS for Azure gives you the ability to reuse what you already have on-premises. It is powered by NGINX Plus and enables you to easily copy your existing NGINX configuration into Azure cloud. This reduces the learning curve often experienced when customers begin to adopt public cloud to gain better security, availability, resiliency, and manageability. Keep reading and I will show you just how easy it is! In 3…2…1…go! Step-by-step Deployment of F5 NGINXaaS for Azure This section will be my quick walkthrough of a new F5 NGINXaaS for Azure deployment. This is based on the F5 NGINXaaS for Azure “Overview and Quickstart”, so click the link and follow along! I will provide my demo screenshots where it requires additional clarity. Otherwise simply follow the docs link above. See you in a couple minutes! Deployment Search for “NGINXaaS” in marketplace or follow this link Select F5 NGINXaaS for Azure and choose "Standard" and subscribe Create an F5 NGINXaaS for Azure deployment in the Azure portal by completing the fields Choose “new VNet” and follow remainder of NGINX Docs steps to deploy Validation The NGINX deployment should take couple minutes to finish. Once complete, review the resources that were created for you. Select the Azure Resource Group Review the VNet, public IP, and Network Security Group (NSG) Click the NGINX Deployment resource to explore setting Add NGINX Configuration If you have your own NGINX configuration file, this is the time to use it. If not, you can use the example nginx.conf below. http { server { listen 80 default_server; location / { default_type text/html; return 200 '<!DOCTYPE html><h2>Welcome to Azure!</h2>\n'; } } } Select the “NGINX Configuration” menu and copy/paste into the code block Confirm and Submit Modify NSG Rules A new NSG is created automatically when choosing the "New VNet" option. Let's create a new rule for port 80 and 443 in order to allow application traffic. This is based on Azure Docs "Create, Change, or Delete a Network Security group". Go to your Resource Group Select the NSG object to modify it Choose "Inbound security rules" and hit "+" Add Add port 80/TCP and port 443/TCP and hit “Add” Test Application At this point, we have a working cluster and demo application. Time to test! Copy the public IP from the NGINX Deployment Open a new web browser and test Congratulations! You now have done a quick install and test of your first F5 NGINXaaS for Azure deployment. Summary This article covered the highlights of the new F5 NGINXaaS for Azure offering. I shared an overview of F5 NGINXaaS for Azure, listed the key capabilities of the new service and how that benefits our customers, and reviewed the problems solved. Lastly, I provided a quick walkthrough to put things in perspective how easy this offer is to deploy. Contact us with any questions or requirements. We would love to hear from you! Resources DevCentral Series - F5 NGINXaaS for Azure F5 NGINXaaS for Azure Docs Blog Introducing F5 NGINXaaS for AzureF5 NGINXaaS for Azure: Multi-Region Architecture
The F5 NGINXaaS for Azureoffering recently announced general availability. Trust me...I've been using it and having fun! In this article, I will show you an example hub and spoke architecture using GitHub Actions and Azure Functions to automate NGINX configurations. As a bonus, I have code on GitHub that you can use to deploy this example. Topics Covered: NGINXaaS for Azure Architecture Explained The NGINXaaS for Azure architecture consists of an F5 subscription as well as customer subscription. F5 subscription - hidden from user, NGINX Plus instances, control plane, data plane Customer subscription - eNICs from VNet Injection, customer network stack, customer workloads F5 Subscription The NGINXaaS offering createsNGINX Plus instances and other related components like NGINX control plane and data plane resources in the F5 subscriptions. These items are not visible to the end user, and therefore result in the operational tasks of upgrades and scaling being managed by the NGINXaaS offering instead of the user. Each NGINX deployment, like other Azure services, is regional in nature. If you need to deploy NGINX closer to the client, then this will require multiple NGINX deployments (ex. westus2, eastus2). Each NGINX deployment will have a unique listener address. You can then use DNS to send clients to an NGINX deployment in the nearest region. Here is an example diagram. Customer Subscription The customer subscription has items like network stacks, Key Vaults, monitoring, application workloads, and more. The NGINX deployment automatically creates ethernet NICs (eNICs) in the customer subscription using VNet Injection and subnet delegation. The eNICs are deployed inside their own Azure Resource Group. They receive IP addressing from the customer VNet and are indeed visible by the user. However, there is no management needed with the eNICs because they are part of the NGINX deployment. Note: In my testing during public preview, I have noticed that Azure lets you manually remove subnet delegation for the NGINX service. Warning...do NOT do this. It will break traffic flow. Hub and Spoke Architecture You can easily make a hub and spoke design with NGINX in the mix using VNet peering. This is a great use case when required to use a shared NGINX deployment across different VNets, environments, or scaling workloads across multiple regions. Recall from earlier that an NGINX deployment will automatically create eNICs in the customer subscription. Therefore, you can control the entry point into the customer environment and the traffic flows. For example, configuring NGINX to use a customer shared VNet with peering gives you a hub and spoke design such as the picture below. This results in the NGINX eNICs being deployed into a customer Shared VNet (hub). Meanwhile the customer places workloads into their own VNets (spokes). Demo Code If this is the first time deploying NGINXaaS for Azure in your subscription, then you will need to subscribe to it in the marketplace. Search for “F5 NGINXaaS for Azure” in marketplace or follow this link Select F5 NGINXaaS for Azure and choose "Public Preview" and subscribe Time to play with code! Click the link below and review the README to deploy the demo example.There are prerequisites to follow. For example, you need to have a GitHub repository that stores the NGINX configuration files. You also need to have an Azure Key Vault and secret containing your GitHub access token. These are explained in the README. GitHub repo - F5 NGINXaaS for Azure Deployment with Demo Application in Multiple Regions After the deployment is done, you have a few options on how to handle NGINX configurations. I will share examples in future articles, but for now go ahead and explore on your own. Refer to the NGINXaaS for Azure documentation "NGINX Configuration" to get started. Summary This article gives an example architecture for deploying the NGINXaaS for Azure offering. I shared details on the different NGINX components, and I also shared demo code to help you explore the solution on your own! Contact us with any questions or requirements. We would love to hear from you! Resources DevCentral Series - F5 NGINXaaS for Azure F5 NGINXaaS for Azure Docs Blog Introducing F5 NGINXaaS for Azure
