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:

  • AWS: IAM Roles for Service Accounts (IRSA) for accessing Amazon S3 and Amazon EBS.
  • Azure: Azure Workload Identity for accessing Azure Blob Storage and Azure managed disks.
  • GCP: Workload Identity Federation for accessing Google Cloud Storage and Compute Engine persistent disks.
    note
    • Portworx Enterprise supports Workload Identity Federation for GCP only on Gardener clusters.
    • Portworx Enterprise does not support GKE Workload Identity. Portworx pods run with hostNetwork: true, which bypasses the GKE metadata server.

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. On GCP, the Portworx Operator mounts a credential configuration ConfigMap directly on the Portworx pods and the Google Cloud SDK reads the projected token from the configured credential_source path.
  • 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.
  • GCP: No mutating webhook is required. The Portworx Operator mounts the credential configuration generated by gcloud iam workload-identity-pools create-cred-config (stored in the ConfigMap you specify in the StorageCluster field spec.workloadIdentity.gcp.credentialsConfigMap) at /etc/workload-identity/, projects the service account token at /var/run/service-account/token, and exposes the credential configuration through the GOOGLE_APPLICATION_CREDENTIALS environment variable.

Why use workload identity​

Traditional cloud credential mechanisms involve provisioning access keys or service principal secrets and rotating them securely, which is 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
  • Gardener 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.
    note

    On an AWS Gardener cluster, workload identity requires Portworx Enterprise version 3.6.2 or later and Portworx Operator version 26.3.0 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; the user-assigned managed identity, custom role, role assignments, and federated credentials on Azure; or the service account, custom role, workload identity pool and provider, IAM bindings, and credential ConfigMap on GCP) and the corresponding StorageCluster configuration are documented in the per-distribution installation topics. Use the topic that matches your platform:

After you complete the installation steps for your platform, Portworx is configured to use workload identity. The StorageCluster includes the required workload identity configuration (spec.workloadIdentity.credentials on AWS and Azure, or spec.workloadIdentity.gcp.credentialsConfigMap on Google Cloud). After you apply the configuration, Portworx Operator restarts the pods as needed. The restarted pods include the projected service account token, volume mount, and environment variables required to authenticate with the cloud provider and access cloud APIs.

What to do next​

After you configure workload identity, you can use it to authenticate CloudSnap backup and restore operations without storing static cloud credentials:

Last updated on
In this topic: