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¶

Support for GCP managed workload identities is coming soon.

Azure¶

Support for Azure managed workload identities is coming soon.

OCI¶

Support for OCI managed workload identities is coming soon.