DEV Community: Martin

Container-Based Applications on Azure - Simple and Kubernetesless

Martin — Fri, 10 Jun 2022 08:09:27 +0000

The justified popularity of containers due to their compactness and portability has opened many opportunities for stacking them into flexible solutions but not seldom with quite complex arrangements.

The search for the best tools to run code placed into a container and then arrange and orchestrate these containers is certainly an interesting one to follow, and the exploration is far from done.

Containers on Azure

Architects and builders are exposed to the dilemma of where and how to deploy their containerized applications on Azure. Azure is very flexible and offers many container options to run your workloads.
A quick search will return you the following options:

Azure Kubernetes Service
Azure App Service
Azure Container Instances
Azure Spring Cloud
Azure Red Hat OpenShift

As the ancient manuscripts say:
"There's no silver bullet. There is no single solution for every use case and every team."

A short visit to the Azure Architecture Centre will give you a great flowchart, which can greatly simplify your decision-making process.

I must admit that Kubernetes, in most cases, is my default choice for orchestrating containers, but if you are starting or migrating a project a lot of times, you might have an application that does not require all of the features Kubernetes offers. Therefore, in this blog, we will go slightly deeper into services that, as of now, allow you to run simple container-based applications, which do not require full-fledged orchestration:

a) Azure Container Instances
b) Azure App Service
c) Azure Container Apps

a) Azure Container Instances

Azure Container Instances (ACI) is a serverless container offer which provides a single pod of Hyper-V isolated containers on demand. ACI offer highly versatile sizing, allowing you to select the exact amount of memory and vCPUs your application requires. Concepts like scale, load balancing, and certificates are not provided with ACI containers.

For example, to scale to five container instances, you create five distinct container instances.

When to use it?

Small-scale batch processing
CI/CD agents
Simple web apps
Task automation

The good things:

A super-Fast and effortless way to run a container in the cloud, from any container registry.
No need to manage Infra/VMs/OS
Per-second billing based on resource requirements (CPU + Memory)

Considerations:

No orchestration capabilities (Auto-scaling, Integrated load balancing, Rolling upgrades, Service discovery, Affinity/anti-affinity …)
Azure Container Instances do not expose direct access to the underlying infrastructure that hosts container groups. This includes access to the Docker API running on the container's host and running privileged containers. If you require Docker interaction, check the REST reference documentation to see what the ACI API supports. If there is something missing, submit a request on the ACI feedback forums.

b) Azure App Service

Azure App Service provides fully managed hosting for web applications including websites and web APIs. These web applications may be deployed using code or containers. Azure App Service is optimized for web applications.

When to use it?

Running Web Applications
Deploying long-running containers/services

The good things:

Managed production environment - App Service automatically patches and maintains the OS and language frameworks for you. Spend time writing great apps and let Azure worry about the platform.
DevOps optimization - Set up continuous integration and deployment with Azure DevOps, GitHub, BitBucket, Docker Hub, or Azure Container Registry. Promote updates through test and staging environments. Manage your apps in App Service by using Azure PowerShell or the cross-platform command-line interface (CLI).
Global-scale with high availability - Scale up or out manually or automatically. Host your apps anywhere in Microsoft's global data center infrastructure, and the App Service SLA promises high availability.

For more please check: Overview - Azure App Service

Considerations:

If you run multiple containers into a shared App Service plan, and some of the containers have unpredictable resource-intensive usage, you might experience the Noisy Neighbor antipattern. Isolating these containers into a new Service Plan is recommended in this case.
To avoid underutilization, understand your CPU, Memory, disk size and disk IOPS requirements of your application to determine the most optimal size of your App Service Plan.

c) Azure Container Apps

Azure Container Apps (ACA)allows you to build Kubernetes-style applications and is greatly simplifying the deployment and management aspects. ACA has an opinion on how things should be done, which is not necessarily bad, since this opinion is based on Azure and Cloud Native best practices, which makes this offer quite appealing to people that want to move fast, have powerful orchestration options, but are not necessarily familiar or big fans of kubectl.

Powered by Kubernetes and open-source technologies like Dapr, KEDA, and envoy.
Supports Kubernetes-style apps and microservices with features like service discovery and traffic splitting.
Enables event-driven application architectures by supporting scale based on traffic and pulling from event sources like queues, including scale to zero.
Support of long-running processes and can run background tasks.

When to use it?

Deploying API endpoints
Hosting background processing applications
Handling event-driven processing
Running microservices

Considerations:

Azure Container Apps doesn't provide direct access to the underlying Kubernetes APIs, which means that you can't just take your existing Kubernetes YAML or Helm charts and use them.
Despite being very flexible ACA is opinionated, it is integrated with services like Envoy for ingress, KEDA for scaling, Log Analytics for monitoring etc.
Currently supports only Linux containers, no support for Windows.

Summa Summarum

You have already greatly improved the portability and ease of deploying your applications just by dockerizing them.

The decision on where and how to deploy your docker images does not have to be a binary decision. Start with your, your team's experience and the application`s resource and operational requirements. Luckily today most cloud providers offer a variety of services that make "Choosing the right tool for the right job" possible and simple.

Use Azure AD workload identity to securely access Azure services or resource from your Kubernetes cluster

Martin — Tue, 19 Apr 2022 12:24:38 +0000

A common challenge architects and developers face when designing a Kubernetes solution is how to grant containerized workload permissions to access an Azure service or resource.

To avoid the need for developers to manage credentials, recommended way is to use Managed identities.

Managed identities provide an identity for applications to use when connecting to resources that support Azure Active Directory (Azure AD) authentication. Applications may use the managed identity to obtain Azure AD tokens.

Besides eliminating the need for managing credentials, Managed identities provide additional benefits like using managed identities to authenticate to any resource that supports Azure AD authentication, including your own applications.

It is worth mentioning that Managed identities can be used without any additional cost.

Azure AD workload identity

Azure AD Workload Identity for Kubernetes is an open-source project that integrates with the capabilities native to Kubernetes to federate with external identity providers. It leverages the public preview capability of Azure AD workload identity federation. With this project, developers can use native Kubernetes concepts of service accounts and federation to access Azure AD protected resources, such as Azure and Microsoft Graph, without needing secrets.

The existing Azure AD Pod Identity project addresses this need. However, the Azure AD workload identity approach is simpler to use and deploy, and overcomes several limitations in Azure AD Pod Identity:

Removes the scale and performance issues that existed for identity assignment.
Supports Kubernetes clusters hosted in any cloud.
Supports both Linux and Windows workloads.
Removes the need for Custom Resource Definitions and pods that intercept IMDS (Instance Metadata Service) traffic.
Avoids the complication and error-prone installation steps such as cluster role assignment.

How it works

In this model, the Kubernetes cluster becomes a token issuer, issuing tokens to Kubernetes Service Accounts. These service account tokens can be configured to be trusted on Azure AD applications. Workload can exchange a service account token projected to its volume for an Azure AD access token using the Azure Identity SDKs or the Microsoft Authentication Library (MSAL).

To read more please following this link.

Sample overview

This sample can be found at:
Azure-Samples/azure-workload-identity-nodejs-aks-terraform (github.com)

Application

In this sample we will deploy our Node.js application that provides information regarding the pod in which it runs and lists all of the roles it has assigned. The roles assigned give us view in the permissions this app has and which services it can connect to and use.

Source code

The main logic of the sample application can be found in App/routes/index.js.

If we examine the getAppRoleAssignments() function we can see that the application uses the @azure/identity library to perform the authorization.

In order to use the AuthorizationManagementClient and obtain the role assignments for our application we need to provide credentials.

The credentials are obtained by simply using the constructor without any need for the developer to provide the client id or client secret.

This credentials are exposed to the application through the workload identity hook.

async function getAppRoleAssignments() {

    const credential = new DefaultAzureCredential();
    const client = new AuthorizationManagementClient(credential, subscriptionId);

    return client.roleAssignments.listForScope(`subscriptions/${subscriptionId}`, { filter: `assignedTo('{${servicePrincipalObjectId}}')` });

}

Infrastructure

All of the required components to run the application and leverage the Azure Workload Identity project are part of the main.tf template in the Infra folder. On the below diagram you can see the main components created by our terraform template:

Walkthrough

This quick start demonstrate how Azure AD Workload Identity works with AKS cluster. We will use Terraform to provision all of the resources required for our Node.js application to run and connect to other Azure services.

Prerequisites

For this tutorial, you will need:

an Azure account - get one for free
installed Azure CLI
installed kubectl
installed Terraform

A) Validate Azure CLI and enable the EnableOIDCIssuerPreview feature

The Azure CLI's default authentication method for logins uses a web browser and access token to sign in. To login with other methods follow the documentation.

Run the login command.

az login

Run the below command and verify that the correct subscription is being used.

az account show

To switch to a different subscription, use az account set with the subscription ID or name you want to switch to.

To use the OIDC Issuer feature, you must enable the EnableOIDCIssuerPreview feature flag on your subscription.

az feature register --name EnableOIDCIssuerPreview --namespace Microsoft.ContainerService

B) Initialize Terraform

In your terminal, clone the following repository, if you haven't already.

git clone https://github.com/gjoshevski/tf-workload-identity

Navigate to the Infra directory. And initialize your Terraform workspace, which will download the providers and initialize them.

terraform init

Make sure the init was successful and you get output similar to the one below.

azureuser@TF-Test:~/tf-workload-identity/Infra$ terraform init

Initializing the backend...

Initializing provider plugins...
- Reusing previous version of hashicorp/random from the dependency lock file
- Reusing previous version of hashicorp/kubernetes from the dependency lock file
- Reusing previous version of hashicorp/helm from the dependency lock file
- Reusing previous version of hashicorp/azurerm from the dependency lock file
- Reusing previous version of hashicorp/azuread from the dependency lock file
- Installing hashicorp/azuread v2.20.0...
- Installed hashicorp/azuread v2.20.0 (signed by HashiCorp)
- Installing hashicorp/random v3.1.2...
- Installed hashicorp/random v3.1.2 (signed by HashiCorp)
- Installing hashicorp/kubernetes v2.10.0...
- Installed hashicorp/kubernetes v2.10.0 (signed by HashiCorp)
- Installing hashicorp/helm v2.5.1...
- Installed hashicorp/helm v2.5.1 (signed by HashiCorp)
- Installing hashicorp/azurerm v3.1.0...
- Installed hashicorp/azurerm v3.1.0 (signed by HashiCorp)

Terraform has made some changes to the provider dependency selections recorded
in the .terraform.lock.hcl file. Review those changes and commit them to your
version control system if they represent changes you intended to make.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
azureuser@TF-Test:~/tf-workload-identity/Infra$

C) Provision the resources

In your initialized directory, run terraform apply and review the planned actions. Your terminal output should indicate the plan is running and what resources will be created.

D) Validate the deployment

In the outputs in your cli you will see the assigned name tou your cluster. Like for example kubernetes_cluster_name = "still-shiner-aks"

The name is auto generated using the random provider for terraform.

Navigate to your Azure Portal where you should see the new AKS cluster created.

Click on the name of the cluster and then under Kubernetes resources click on Services and ingresses. Here you will see the External IP, which you can use to access the web app.

Open the External IP in your browser. You will see the web app that will display stats about your pod and in the App Role Assignments you will see a list of all of the roles that this pod can use to call Azure services. At this point you will see that there is only one role in the list. This is a custom role created by our terraform deployment and gives permissions to the application to list all of the assigned roles.

To see the definition of this role go to the Infra/main.tf and check line 222:
resource "azurerm_role_definition" "azurerm_custom_role"

Let's navigate back to the Azure portal and grant additional access to this application. In this example we will grant the application Read access so it can view all the resources of the AKS cluster.

Navigate to the AKS cluster and open the Access control (IAM) page.

Click Add > Add role assignment
On the Roles tab, select a role Reader and click Next.
On the Members tab, select User, group, or service principal to assign the selected role
Click +Select members
In the list find the service principal, that will have the same pet name as you AKS cluster, but it will end with the -app suffix.
After selecting it, click on Review + assign.
After the Role assignment is created navigate back to the web application. Now you will see the new role that we assigned in the list.

Pod description

If you check the kubernetes_deployment that we use you will notice that we set only 2 env vars, AZURE_SUBSCRIPTION_ID and AZURE_SERVICE_PRINCIPAL_OBJECT_ID which are requred to call the API that returns the roles assigned to a specific principal.

But we do not provide any keys which we can use to authenticate.

Navigate to the Workloads page.

Expand the app-example workload and then expand one of the pods from the list below.

Then examine the YAML definition of this pod.

In the container specs, you will notice that there are 3 env vars exposed AZURE_TENANT_ID, AZURE_FEDERATED_TOKEN_FILE, AZURE_AUTHORITY_HOST, by the Azure AD Workload Identity for Kubernetes.

If this env vars are not present your application will not be able to authenticate!

In the case when the env vars are not present, follow the next steps:

verify that azure-workload-identity helm chart was successfully created
the azure-wi-webhook-controller-manager pods are running without any errors
redeploy the app-example deployment and verify if the new pods got populated with the env vars

Clean up your workspace

Congratulations, you have provisioned an AKS cluster, deployed the application and managed to get access to Azure services using the Azure AD workload identity.

To clean the resources please run:

terraform destroy

DEV Community: Martin

Container-Based Applications on Azure - Simple and Kubernetesless

Containers on Azure

a) Azure Container Instances

b) Azure App Service

c) Azure Container Apps

Summa Summarum

Further Reading

Use Azure AD workload identity to securely access Azure services or resource from your Kubernetes cluster

Azure AD workload identity

How it works

Sample overview

Application

Source code

Infrastructure

Walkthrough

Prerequisites

A) Validate Azure CLI and enable the EnableOIDCIssuerPreview feature

B) Initialize Terraform

C) Provision the resources

D) Validate the deployment

Clean up your workspace