Condensed Transcript of "Designing a Secure Cloud-Native Architecture using Kubernetes on Azure"


Let’s say you want to create an application and to deploy this to the Cloud and you decided to adopt container technology.

So how do we actually get started?

As a developer, you have your code your developing on your local machine. Then you push this source code to some source control repository for good measure, whether that’s GitHub or somewhere else, you just do that.

GitHub Actions makes it easy to automate & kick off workflows with GitHub events like push, issue creation, or a new release. Actions are individual tasks that you can combine to create jobs and customize your workflow.

You can set up some CI/CD process, a continuous integration and continuous deployment process on top of that to actually build, take that code, and build this using the CI/CD process into a container image, which then gets pushed into a container registry or a non-image repository somewhere. This could be Docker Hub or if you’re using Azure, this is naturally going to be Azure Container Registry.

Azure Container Registry or ACR in short, it’s a geo-replicated, highly available container registry that you can use for all your container process.

So once you have your image in the container registry, where they actually go from there?

On Azure, you can deploy this image to Azure Kubernetes service. Kubernetes if you are not familiar with it, is a container orchestrator. The purpose of the container orchestrator is to take container images and deploy them on a cluster of machines, while also making sure that the source utilization is respected that if one of the machines goes down, the workloads get migrated to another machine so that it can maintain the up-time as well as the scalability requirements of your application. The Azure Kubernetes Service, is a managed service for Kubernetes and it allows you to do so.

From that point forward, the deployment pipeline would then use that definition that you created when, for example, if using GitHub actions to deploy this container image.

But first, it would create a namespace. A namespace in Kubernetes, think of it as like a project or it’s boundary where a bunch of related application components live together. You can apply some security constraints on the namespace, some resource constraints on the namespace. In general, it’s best practice to deploy each application its own namespace. So the way this works is that within this namespace you’d be creating a deployment.

A Kubernetes deployment defines where are the images that you want to be deploying from. In this case, lets say you’re deploying this application and the images are living on Azure Container Registry. In

the deployment definition, you’d say that these are my images stored in this container registry and this is how you can authenticate against this container registry.

Deployments manage Pods, the smallest unit of control within Kubernetes cluster. The Pods run on one or more containers. The Pods would then initiate the image pull so that they can get the image outside of Azure Containers to actually deploy that up to your cluster. Once this is running here, if you want to expose this application to the outside world, you would create a Kubernetes service.

A Kubernetes service, is a way that you can load balance traffic across Pods that probably are deployed across multiple nodes in the cluster. The service is able to direct traffic to the right node which hosts the Pod that is running your application based on a mechanism called Labels, so it can identify where the applications are hosted.

What are the kind of the options for hosting my data workloads in Azure?

I know some people that maybe super happy about Kubernetes being the operation control plane, and they run the database right inside of AKS. So while you can certainly run a number of databases within the Kubernetes cluster, for example, you can spin up a MySQL container image and run it there, the better option would be to rely on a managed service and externalize the state outside of the cluster.

The reason being is that containers, because they’re lightweight, it’s a lot easier to automate bringing up and down services and applications if the state is stored outside of the cluster. So think of it this way, if you’re able to go ahead and delete this cluster and then re-deploy every workload that comes with it comfortably, you’re in a good shape because then you’re able to respond easier to disasters. You’re able to scale out and stamp out additional locations to deploy applications a lot easier than if your state is actually inside the cluster, and then you have to worry about, “Okay. Now what? How do I move this data or how do I backup my database from within the container?”.

Containers do not necessarily make it any easier to manage databases. Whatever work you would be doing to manage the database, if you’re running this on a virtual machine, you’d still have to do that on a container. So for that reason, you can connect your application to a number of managed database providers on Azure, whether that application is using PostgreSQL, if it’s using MySQL, or let’s say, something like MongoDB. You can leverage these managed services from Azure as well as enrich your application with things like AI services, with Cognitive Services, while focusing on what you do best, which is actually coding the app versus trying to maintain that structure on a cluster.

At the same time, you can configure monitoring and logging through built-in Azure Monitor so that you can set up alerts and identify or understand how the cluster is working in case anything comes up.

Azure Kubernetes Service lives within an Azure Virtual Network, and the nodes that you deploy within that form your cluster actually living in a subnet, and then this service that you create as part of your deployment, it actually integrates or interacts with an Azure Load Balancer. So the services create rules in the Azure Load Balancer, which lives on its own subnet as well, and then this allows you to leverage and manage the Azure Load Balancer, to expose those services to the Internet or even to other consumers within the same virtual network. Now, an Azure Load Balancer is a layer 4 Load Balancer. If you need to get more capabilities through a layer 7 Load Balancer, you can integrate this with something else like an Ingress or an Azure Application Gateway.

When it comes to securing your application, there are a couple of points that you can do. Azure Security Center integrates with the Azure Kubernetes Service. It can surface vulnerabilities that are detected within your application or within your cluster deployment, it can detect bad configuration as well.

Additionally, Azure Security Center also integrates with the Azure Container Registry. In case you are building your application against a container image that ends up having a vulnerability of some sort, Azure Security Center will scan your container registry and then it will alert you if that’s the case so that you can fix that by updating your container registry based image.

When it comes to securing access to the cluster, you can configure role-based access control against Azure Active Directory. By doing that, your developers can then use their Azure AD accounts to be able to interact with the cluster. You can assign users and groups and do a lot of neat things when it comes to authentication by integrating with Azure AD.

Also, since you’re exposing this application to the Internet, you can leverage something like the Azure Application Gateway and enable the web application firewall functionality. When you do so, the Application Gateway then filters all of the incoming traffic into your cluster, and it’s actually able to detect and block common attacks that work with the OS, for example, attack vectors.

Inbound traffic will flow through the Application Gateway in this case, and what about securing your outbound traffic?

For many of the customers, the situation is that they have rules that they need to secure any traffic that goes outside of the cluster as well. So for that case, you can integrate with the Azure Firewall, and then all of the egress traffic would then pass through that Azure firewall depending on the rules that you allow in there, so that you are monitoring actually all of the traffic that’s coming in and going out of your cluster, in that case, between the cluster services and the Internet, and then naturally, because you enable the Azure firewall, the only way that external traffic would be allowed to, let’s say, your databases or Security Center, or container registry, you have to use either for services that are enabled with Azure Private Link, or Azure Service Endpoints, the Traffic would go through either of these connection choices.

Fairly often when you have that firewall subnet , large customers may have a separate subscription with a hub and spoke, where they may have that firewall or other appliances or CMs, things like that, it maybe some shared services for the enterprise. So that way, you may have AKS clusters or other services and multiple subscriptions going back to a hub where maybe that firewall is pinned.

Access to many of the Azure services can actually be done through managed identity now. Securing let’s say your connection strings can also be done through Azure Key Vault. So you can actually store sensitive information on Azure Key Vault and then pull those from Azure Key Vault directly into your Azure Kubernetes Service on the application that’s running on your Azure Kubernetes Service, so that you don’t even have to store or expose these sensitive connection strings within the application or store them in the connections.

On the Azure Architecture Center, you’ll have lots of best practice and reference on architectures for designing and securing applications. We also have a number of customer use cases that are published on customers.Microsoft.com, where you’ll find other customers who have gone through similar experiences of building applications and what did they learn out of them, and also we actually see the architecture itself and the customer story.

Once we start having multiple of these Kubernetes clusters, you might want to apply some governance policies on them. For this reason, we have created this integration with the Azure Policy. Now, you can actually apply many of these governance policies. For example, that all of the deployments need to have certain labels applied on them, or all of the clusters need to have this DaemonSet running in there because it’s mandatory for my organization to run. Right now, you can control this with the Azure Policy. There are a number of built-in Azure policies as well that can govern, for example, resource usage across namespaces. So from a control perspective, you can apply this at scale and from a central location from the Azure policy.

Comments

Post a Comment