Leveraging Workload Identity with Rafay's GitOps Approach - Part 2

In continuation of our Part 1 of our blog introducing Workload Identity for Azure AKS,this is Part 2 where will explore how to use Workload Identity with the Rafay's GitOps approach, enabling your Kubernetes pods to securely access Azure resources.

Workload Identity with Rafay's GitOps Approach

In this GitOps approach, we will explore how to configure Workload Identity for Azure AKS clusters. This methodology helps maintaining version controlled declarative specifications within Git repositories, enhancing both manageability and security for your AKS environments.

Prerequisites

1. Configure the GitOps Pipeline on the Rafay Platform:

   • Ensure that you have access to the Rafay platform and have set up your GitOps pipeline according to the Gitops documentation.

2. Set Up System Sync Stage:

   • Establish a system sync stage within your pipeline to ensure that changes in your Git repository are automatically reflected in your AKS cluster.

3. Activate Your Pipeline:

   • Activate your GitOps pipeline to begin monitoring the repository and deploying changes as they occur.

---

Enable Workload Identity and OIDC Issuer Profile

When creating a new AKS cluster or updating an existing one with Workload Identity configuration, the first step is to enable the OIDC Issuer and Workload Identity profiles as outlined below. After updating the configuration, commit the changes to the provided cluster configuration file.

apiVersion: infra.k8smgmt.io/v3
kind: Cluster
metadata:
  labels:
    a: b
  name: azure-demo-1
  project: demo
spec:
  blueprintConfig:
    name: minimal
  cloudCredentials: demo_azure
  config:
    kind: aksClusterConfig
    metadata:
      name: azure-demo-1
    spec:
      managedCluster:
        apiVersion: "2024-01-01"
        identity:
          type: SystemAssigned
        location: centralindia
        properties:
          apiServerAccessProfile:
            enablePrivateCluster: true
            enablePrivateClusterPublicFQDN: false
          disableLocalAccounts: false
          dnsPrefix: azure-demo-1-dns
          enablePodSecurityPolicy: false
          enableRBAC: true
          kubernetesVersion: 1.30.0
          networkProfile:
            loadBalancerSku: standard
            networkPlugin: kubenet
          oidcIssuerProfile:
            enabled: true
          powerState:
            code: Running
          securityProfile:
            workloadIdentity:
              enabled: true
        sku:
          name: Base
          tier: Free
        tags:
          email: ankur@rafay.co
          env: pm
        type: Microsoft.ContainerService/managedClusters
      nodePools:
      - apiVersion: "2024-01-01"
        name: primary
        properties:
          count: 1
          enableAutoScaling: true
          maxCount: 1
          maxPods: 110
          minCount: 1
          mode: System
          orchestratorVersion: 1.30.0
          osType: Linux
          type: VirtualMachineScaleSets
          vmSize: Standard_B4ms
        type: Microsoft.ContainerService/managedClusters/agentPools
      resourceGroupName: ankurp
  type: aks

This commit action will trigger your pipeline, which will subsequently update the cluster with the specified configuration shown above.

Once the Workload Identity profile is enabled, you will see the Workload Identity webhook deployed on the system's primary node.

---

Create Workload Identity and Service Accounts

After enabling the OIDC Issuer and Workload Identity profiles, you have the option to either integrate the workload identity and service account configuration into the previous setup or handle it separately. In this step, we will focus on creating the Workload Identity and Service Account configurations, following the initial profile setup.

apiVersion: infra.k8smgmt.io/v3
kind: Cluster
metadata:
  labels:
    a: b
  name: azure-demo-1
  project: demo
spec:
  blueprintConfig:
    name: minimal
  cloudCredentials: demo_azure
  config:
    kind: aksClusterConfig
    metadata:
      name: azure-demo-1
    spec:
      managedCluster:
        apiVersion: "2024-01-01"
        identity:
          type: SystemAssigned
        location: centralindia
        properties:
          apiServerAccessProfile:
            enablePrivateCluster: true
            enablePrivateClusterPublicFQDN: false
          disableLocalAccounts: false
          dnsPrefix: azure-demo-1-dns
          enablePodSecurityPolicy: false
          enableRBAC: true
          kubernetesVersion: 1.30.0
          networkProfile:
            loadBalancerSku: standard
            networkPlugin: kubenet
          oidcIssuerProfile:
            enabled: true
          powerState:
            code: Running
          securityProfile:
            workloadIdentity:
              enabled: true
        sku:
          name: Base
          tier: Free
        tags:
          email: ankur@rafay.co
          env: qa
        type: Microsoft.ContainerService/managedClusters
      nodePools:
      - apiVersion: "2024-01-01"
        name: primary
        properties:
          count: 1
          enableAutoScaling: true
          maxCount: 1
          maxPods: 110
          minCount: 1
          mode: System
          orchestratorVersion: 1.30.0
          osType: Linux
          type: VirtualMachineScaleSets
          vmSize: Standard_B4ms
        type: Microsoft.ContainerService/managedClusters/agentPools
      resourceGroupName: ankurp
      workloadIdentities:
      - createIdentity: true
        metadata:
          location: centralindia
          name: workload-demo-test1
          resourceGroup: demo-rg
          tags:
            owner: lead
        roleAssignments:
        - name: Key Vault Secrets User
          scope: /subscriptions/a2252eb2-7a25-432b-a5ec-e18eba6f26b1/resourceGroups/demo-rg/providers/Microsoft.KeyVault/vaults/demovault
        serviceAccounts:
        - createAccount: true
          metadata:
            name: sa
            namespace: demons
  type: aks

After updating the configuration and committing the changes through Git, you should see another pipeline trigger that will subsequently update the cluster resources. Once the cluster configuration is updated, you will also see the service account created on the cluster.

You can now leverage this service account in your Kubernetes pods to interact with Azure Key Vault. In this case, the role assigned to the Workload Identity is specifically for accessing Key Vault resource

---

Conclusion

Workload Identity significantly enhances security and simplifies identity management for Kubernetes workloads in Azure AKS by leveraging Azure managed identities, eliminating the need for developers to manage sensitive secrets like connection strings or API keys. When integrated with Rafay's GitOps approach, this combination streamlines the deployment process, enabling teams to manage these configurations through Git and ensuring that all changes are tracked and version controlled.

---