Managed Workload Identities¶

Overview¶

Helm amenities or service workloads might require permissions necessary to call cloud-native services outside the Kubernetes cluster. For example, a custom component might need to publish messages to an external queue, write objects to a bucket, or access a managed database.

The managed workload identities feature allows you to define cloud permissions that your workloads need and use the resulting cloud identity from the Kubernetes service account. Omnistrate will provision all required cloud provider-specific entities during account onboarding and will create federated access so the workloads can use such external identity.

The identity and federation workflow is cloud-specific. You define the permissions in the deployment cell configuration, and Omnistrate handles the provider-specific role, service account, trust, and federation details required for that cloud.

Cloud Providers¶

The following sections describe the managed workload identity flow for each supported cloud provider. The AWS flow is documented first; the other provider sections will be expanded as their examples are added.

AWS¶

Create an AWS managed workload identity¶

Define the identity in the managedIdentities section of the AWS amenities template. The example below creates a queue-writer identity with permission to send messages only to SQS queues whose names begin with orders-. Service account binding specifies which Kubernetes service account will be allowed to use the identity:

managedIdentities:
  - identifier: queue-writer
    description: Allows the workload to publish messages to application queues.
    bindings:
      - serviceAccount:
          namespace: queue-system
          name: queue-writer
    permissions:
      policies:
        aws: |
          {
            "Version": "2012-10-17",
            "Statement": [
              {
                "Effect": "Allow",
                "Action": [
                  "sqs:SendMessage"
                ],
                "Resource": "arn:aws:sqs:*:*:orders-*"
              }
            ]
          }

When the account is onboarded, Omnistrate creates the AWS IAM role and its policy for this managed workload identity in the customer account. You do not need to create the role manually. Omnistrate also configures the AWS federation needed for Kubernetes workloads to use the role during deployment cell provisioning.

Resolve the ARN of the managed identity role in the system parameters¶

At deployment time, Omnistrate exposes the role ARN through the $sys.deploymentCell.aws.managedWorkloadIdentities["managedIdentityIdentifier"].roleARN system parameter. Replace managedIdentityIdentifier with the identity's identifier value. For the example above, use $sys.deploymentCell.aws.managedWorkloadIdentities["queue-writer"].roleARN. The value is resolved for the target deployment cell, so the manifest does not need to contain a hard-coded AWS account ID or role ARN.

Use the role from a Kubernetes service account¶

Annotate the service account used by the workload with the resolved role ARN. For Amazon EKS, the eks.amazonaws.com/role-arn annotation associates the service account with the IAM role:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: queue-writer
  namespace: application
  annotations:
    eks.amazonaws.com/role-arn: '{{ $sys.deploymentCell.aws.managedWorkloadIdentities["queue-writer"].roleARN }}'

Such a service account can be defined in the amenity template or a service plan spec (for use by service instance).

GCP¶

Create a GCP managed workload identity¶

Define the identity in the managedIdentities section of the deployment cell configuration. The example below creates a queue-writer identity with the roles/pubsub.publisher role. Service account bindings specify which Kubernetes service accounts are allowed to use the identity:

managedIdentities:
  - identifier: queue-writer
    description: Allows the workload to publish messages to Pub/Sub topics.
    bindings:
      - serviceAccount:
          namespace: queue-writer
          name: queue-writer
    permissions:
      roles:
        gcp:
          - name: roles/pubsub.publisher

When the account is onboarded, the account setup script creates the GCP service account for this managed workload identity in the customer project. Omnistrate configures the GKE Workload Identity federation needed for Kubernetes workloads to authenticate as the service account during deployment cell provisioning.

Resolve the service account email in the system parameters¶

At deployment time, Omnistrate exposes the service account email through the $sys.deploymentCell.gcp.managedWorkloadIdentities["managedIdentityIdentifier"].serviceAccountEmail system parameter. Replace managedIdentityIdentifier with the identity's identifier value. For the example above, use $sys.deploymentCell.gcp.managedWorkloadIdentities["queue-writer"].serviceAccountEmail. The value is resolved for the target deployment cell, so the manifest does not need to contain a hard-coded project ID or service account name.

Use the identity from a Kubernetes service account¶

Annotate the service account used by the workload with the resolved GCP service account email. For GKE Workload Identity, the iam.gke.io/gcp-service-account annotation associates the Kubernetes service account with the GCP service account:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: queue-writer
  namespace: queue-writer
  annotations:
    iam.gke.io/gcp-service-account: '{{ $sys.deploymentCell.gcp.managedWorkloadIdentities["queue-writer"].serviceAccountEmail }}'

You can define such a service account in an amenity template or a plan spec (for use by a product instance).

Azure¶

Create an Azure managed workload identity¶

Define the identity in the managedIdentities section of the deployment cell configuration. The example below creates a blob-writer identity with the Storage Blob Data Contributor role. Service account bindings specify which Kubernetes service accounts are allowed to use the identity:

managedIdentities:
  - identifier: blob-writer
    description: Read, write, and delete Azure Storage containers and blobs.
    bindings:
      - serviceAccount:
          namespace: blob-writer-ns
          name: blob-writer
    permissions:
      roles:
        azure:
          - name: "Storage Blob Data Contributor"

When the account is onboarded, the account setup script creates the Azure application registration and associated service principal for this managed workload identity in the customer's Entra ID tenant. Omnistrate configures the federated identity credential needed for Kubernetes workloads to authenticate as the service principal during deployment cell provisioning.

Resolve the client ID in the system parameters¶

At deployment time, Omnistrate exposes the application client ID through the $sys.deploymentCell.azure.managedWorkloadIdentities["managedIdentityIdentifier"].clientID system parameter. Replace managedIdentityIdentifier with the identity's identifier value. For the example above, use $sys.deploymentCell.azure.managedWorkloadIdentities["blob-writer"].clientID. The value is resolved for the target deployment cell, so the manifest does not need to contain a hard-coded subscription or client ID.

Use the identity from a Kubernetes service account¶

Annotate the service account used by the workload with the resolved client ID. For AKS Workload Identity, the azure.workload.identity/client-id annotation associates the Kubernetes service account with the Azure application:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: blob-writer
  namespace: blob-writer-ns
  annotations:
    azure.workload.identity/client-id: '{{ $sys.deploymentCell.azure.managedWorkloadIdentities["blob-writer"].clientID }}'

You can define such a service account in an amenity template or a plan spec (for use by a product instance).

OCI¶

Support for OCI managed workload identities is coming soon.