Securing any environment requires multiple lines of defense, and it's usually pretty complex. And that's no different when it comes to Containers.
Luckily for us, tools like Azure Container Registry and Security Center provide the right features to secure our container end-to-end workflow, quickly and easily.
Intro
When it comes to containers and container security, there are many things you need to consider.
- How to create the images?
- Where to store them?
- How to deploy?
- What to take care of after the deployment?
Those are just some of the most commonly asked questions...
I've already talked in some previous posts about how I like to build my container images (VIDEO) and how I do deploy them in enterprise scenarios (VIDEO), so I won't cover that here. I highly encourage you to check them out.
What I will cover here, instead, is how to use Azure Container Registry, Azure Security Centre and Azure Policies to secure your containers when they leave your controlled environment, if you will.
Video
If you are a visual learner, simply prefer to watch and listen instead of reading, or you want to see this in action, here you have the video with the whole explanation, which to be fair is much more complete than this post.
If you rather prefer reading, well... let's just continue :)
About ACR
Azure Container Registry in fact recently announced the general availability of features like Azure Private Link, customer-managed keys, dedicated data-endpoints, and Azure Policy definitions, as well as the integration with Azure Security Center for the security scan of container images. These features provide tools to secure Azure Container Registry as part of the container end-to-end workflow, and I will focus on those, one by one.
ACR Customer-managed Keys
First off, let's talk about Customer-Managed keys.
By default, when you store images and other artifacts in an Azure Container Registry, content is automatically encrypted at rest with Microsoft-managed keys.
But if you or your organization have stricter compliance needs, or want to be in full control, you can choose customer-managed keys that are created and maintained in your Azure Key Vault instance.
There are few prerequisites, first you'd need to create a Managed Identity for the ACR.
az identity create \
--resource-group <resource-group-name> \
--name <managed-identity-name>
Then, you'd need to create a KeyVault, if you don't have one already.
And of course you'd need to enable the Managed identity to access that KeyVault.
Just go to Access Policies > Add > and select your Managed Identity under Select Principal
You just need the Get, Unwrap Key and Wrap Key permisisons under Key permissions
Lastly on KeyVault, you need to create a Key for securing your ACR.
Just go to the Key section of KeyVault, Select + Generate/Import and enter a unique name for the key.
And finally now you can create your container registry. (Video with full explanation and examples)
Select the Premium SKU and, in the Encryption section:
After enabling a customer-managed key in a registry, you can perform the same registry operations that you perform in a registry that's not encrypted with a customer-managed key.
And of course you can change that key down the road.
Just go to Encryption under Settings > Change Key > Select Key > Choose the same one > Create a key > Generate, Create > Save
Of course you can also use another exhisting key, if you want.
There are few things to note here:
- This feature is available only in the Premium container registry service tier.
- You can currently enable a customer-managed key only when you create a registry.
- After enabling a customer-managed key on a registry, you can't disable it.
Private Links
Let's move now to Private Links.
Container Registry previously had the ability to restrict access using firewall rules. Now, with the introduction of Private Link, the registry endpoints are assigned private IP addresses, routing traffic within your virtual network and the service through a Microsoft backbone network.
This of course means not only tighter security when accessing the Azure Container Registry directly, for example for pushing images, but also when communicating with other Azure Services which are either in a VNET or that support Private Link, like AKS.
You can set up a private link when you create a registry, or you can add a private link to an existing registry.
To add it to an existing one, go to Networking > Private Endpoints > + Private Endpoint and follow the wizard to select the Container Registry and the VNet you want to connect to. (Video with full explanation and examples)
Now your registry is accessible only from within that VNET and its peered VNETs, if any.
This also means that you would need to push your images to the Container Registry from a VM that is in the same Virtual Network where the Private Link is configured. But this is not a big deal using Azure DevOps, you can just register a small VM in that VNET as Pipeline Self-hosted agent and you're good to go, as long as you have either the docker CLI or the Azure CLI on that VM of course.
Dedicated Data Endpoints
As we have seen, Private Link is the most secure way to control network access between clients and the registry as network traffic is limited to the Azure Virtual Network.
If Private Link can't be used, for example because you want to use your container registry with Azure Container Instances which at the time of recording doesn't support Private Link yet, then dedicated data-endpoints can be enabled to minimize data exfiltration concerns.
Enabling dedicated data endpoints means you can configure firewall rules with fully qualified domain names rather than a rule with wildcard for all storage accounts.
You can enable dedicated data-endpoints using the Azure portal or the Microsoft Azure CLI.
Once again, on the portal go to Networking > Public access > Enable dedicated data endpoint
The data endpoint (or endpoints) will appear in the portal.
As you can see, the data endpoints follow a regional pattern:
<registry-name>.<region>.data.azurecr.io.
And the cool part is that if you have a geo-replicated registry, enabling data endpoints creates endpoints in all replica regions.
ACR Built-in Policies
Next one is a feature that has been GAed pretty recently and I have to say I quite like it.
I'm talking about the built-in Azure Policy definitions in Azure Container Registry.
In my opinion those policies are quite important, because having security capabilities will secure your workflows only if they’re implemented. The Azure built-in policies assure your Azure resources are following the best security practices.
And best of all, there are no charges for using Azure Policy!
All you have to do is going to Azure Policy > Assignments > Assign Policy and then search for container registries in the "Policy Definition" box
Just click on the one you want to use, and select the scope (whole Subscription or a single Resource Group). And you're done.
It takes about 30 minutes for the new policies to be applied.
Then you can go to "Compliance" to see whether your container registries implement your policies and the best practices or not.
Using Azure Policy, you can ensure that your registries stay compliant with your organization's needs. And this is pretty important.
Azure Security Center Container Image Scan
Last but not least, let's talk about Security for Container Images.
If you're on Azure Security Center's standard tier, you can add the Container Registries bundle. This optional feature brings deeper visibility into the vulnerabilities of the images in your registries and ensures that Security Center is ready to scan images that get pushed to the registry.
Whenever an image is pushed to your registry, Security Center is notified via WebHooks and automatically scans that image.
The image is pulled from the registry and it's run in an isolated sandbox with the Qualys scanner that extracts a list of known vulnerabilities.
Security Center then filters and classifies the findings from the scanner.
When an image is healthy, Security Center marks it as such, otherwise it generates security recommendations for the issues to be resolved.
By only notifying when there are problems, Security Center reduces the potential for unwanted informational alerts.
When the scan completes (typically after approximately 2 minutes, but can be up to 15 minutes), findings are available as Security Center recommendations like this one:
Conclusion
Alright, that's it for today. That was a lot of stuff, hope you stayed with me the whole time.
Let me know in the comment section below if you're already using any of these features or, if not, how you take care of your container workflows.
Top comments (1)
What do you think? How do you secure your containers and container workflows?