Skip to main content
Version: 3.6

Workload identity for cloud operations in Portworx

Portworx supports workload identity to securely access cloud resources used by CloudSnap backups and CloudDrive provisioning, without using static cloud credentials or assigning permissions at the node level.

Workload identity allows applications running in Kubernetes to authenticate with external cloud services by using a Kubernetes ServiceAccount (KSA) and an OIDC (OpenID Connect) token issued by the cluster. Portworx Operator configures this integration and injects short-lived tokens into Portworx pods through projected service account tokens. The cloud provider validates the OIDC token through a federated trust relationship and issues temporary credentials, which Portworx uses at runtime to call cloud APIs.

This approach eliminates the need to store long-lived credentials in Kubernetes Secrets, improves security, simplifies credential management, and supports enterprise compliance requirements for cloud-based Kubernetes environments.

The supported integrations are:

How it works​

When this feature is configured:

  • The Portworx service account is annotated or bound to a cloud identity (AWS IAM role or Azure managed identity client ID).
  • The Portworx Operator ensures pods are injected with a projected service account token and the environment variables or credential configuration required by the cloud SDK.
  • On AWS and Azure, a cloud-provider mutating webhook running on the cluster mutates the Portworx pods to add the projected token volume, volume mount, and required environment variables.
  • The cloud SDK inside Portworx exchanges the projected token for short-lived cloud credentials and uses them to call the cloud APIs.

How identity is delivered to the Portworx pods differs by cloud provider:

  • AWS: eks-pod-identity-webhook. This webhook is included by default on EKS and ROSA. On other AWS distributions running on EC2, you must deploy it manually.
  • Azure: azure-workload-identity webhook. On AKS you can enable it as a cluster feature. For self-managed clusters, you must install it manually.

Why use workload identity​

Traditional cloud credential mechanisms involve provisioning access keys or service principal secrets and rotating them securely—an operational and security risk. Workload identity offers the following benefits:

  • Eliminates long-lived access keys and static credentials.
  • Avoids granting cloud IAM permissions to the entire Kubernetes node.
  • Enforces least-privilege access at the workload level.
  • Automatically injects short-lived credentials, scoped to specific pods, that are rotated by the platform.

Supported platforms​

This feature is supported on the following AWS-based Kubernetes distributions:

  • Amazon Elastic Kubernetes Service (EKS)
  • Red Hat OpenShift Service on AWS (ROSA)
  • Google Anthos on AWS

Prerequisites​

Before configuring workload identity on AWS, ensure that the following prerequisites are met:

  • A Kubernetes cluster on the AWS platform.
  • Portworx Enterprise version 3.4.0 or later.
  • Portworx Operator version 25.3.1 or later.
  • An OIDC provider linked to your Kubernetes cluster. For more information, see Create an OpenID Connect (OIDC) identity provider in IAM.
  • The Pod Identity Webhook is deployed and running:
    • Included by default in EKS and ROSA clusters.
    • For other clusters running on EC2 instances, you need to manually deploy the webhook. For more information, see Amazon EKS Pod Identity Webhook.
      important

      After cloning the repository, edit the deployment-base.yaml file to include --aws-default-region <aws-region> flag in the spec.template.spec.containers.command field before deploying the webhook.

    If you plan to deploy the webhook after installing Portworx, you must manually restart the Portworx pods after deploying the webhook.

Configure workload identity​

The cluster preparation steps (creating the IAM role and trust policy on AWS, or the user-assigned managed identity, custom role, role assignments, and federated credentials on Azure) and the corresponding StorageCluster configuration are documented in the per-distribution installation topics. Use the topic that matches your platform:

After completing the steps in your installation topic, your Portworx installation is configured for workload identity (the StorageCluster includes the spec.workloadIdentity.credentials block on AWS and Azure). After the configuration is applied, the Portworx Operator restarts the pods as needed. Following the restart, Portworx pods contians the projected token volume, volume mount, and environment variables required by the cloud SDK to authenticate and make API calls.

Last updated on