Skip to main content

Documentation Index

Fetch the complete documentation index at: https://porter-docs-azure-managed-identity-ga.mintlify.app/llms.txt

Use this file to discover all available pages before exploring further.

Porter services can authenticate to your cloud accounts without you having to embed static access keys or service-principal secrets in environment variables. Instead, each pod assumes a cloud identity at runtime via your cloud provider’s native workload-identity mechanism. This page covers how to configure these identities for each supported cloud provider, and how to scope their permissions to follow the principle of least privilege.

​
AWS

Porter uses EKS Pod Identity to associate an IAM role with a service’s pod. Your application code can then use the default AWS SDK credential chain (e.g. DefaultAWSCredentialsProviderChain in Java, aws.config.LoadDefaultConfig in Go, boto3.Session() in Python) and credentials will be resolved automatically — no access keys, no sts:AssumeRole calls in application code.

​
How it works

When you attach an IAM role to a service, Porter creates an EKS Pod Identity Association on your cluster that maps the service’s Kubernetes service account to the IAM role you specify. At runtime, the EKS Pod Identity agent injects short-lived credentials for that role into the pod. You are responsible for creating the IAM role and granting it the permissions it needs. Porter does not create the role or modify its permissions.

​
Step 1 — Create the IAM role

In your AWS account, create a new IAM role with two things:
  1. A trust policy that allows EKS Pod Identity to assume the role: 
    {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "pods.eks.amazonaws.com" },
      "Action": ["sts:AssumeRole", "sts:TagSession"]
    }
  ]
}
  2. A permissions policy scoped to only the AWS APIs and resources your service needs.
We strongly recommend following the principle of least privilege: avoid wildcard actions and Resource: "*", and create a dedicated role per service rather than sharing roles across workloads.

​
Step 2 — Attach the role to your service

In the Porter dashboard, open the service you want to grant access to and scroll to the IAM Role Connection section. Toggle the connection on and enter the IAM role name or full ARN: IAM Role Connection UI On the next deploy, your pods can use the role immediately — no application restart logic required.
If you manage your app config as code, you can declare the same connection in porter.yaml:
services:
  - name: api
    # ...
    connections:
      - type: awsRole
        role: my-app-api-role
See Connections in porter.yaml for the full schema.

​
Azure

Porter uses Azure Workload Identity to federate a service’s Kubernetes service account with a User Assigned Managed Identity (UAMI) in your Azure subscription. Your application code can then use DefaultAzureCredential (or any credential type that supports workload identity) and Azure will issue tokens for the UAMI on the pod’s behalf.

​
How it works

When you attach a managed identity to a service, Porter creates a federated identity credential on the UAMI you specify. The credential trusts the AKS cluster’s OIDC issuer to vouch for a specific Kubernetes service account. At runtime, the pod presents a projected OIDC token and Azure exchanges it for an access token scoped to the UAMI. You are responsible for creating the UAMI and granting it role assignments. Porter does not create the UAMI or modify its permissions.

​
Step 1 — Create a User Assigned Managed Identity

In the same Azure subscription as your AKS cluster, create a User Assigned Managed Identity and grant it the Azure RBAC role assignments needed to access the specific resources your service will call. We strongly recommend following the principle of least privilege: scope role assignments to individual resources rather than resource groups or subscriptions, prefer narrow data-plane roles (e.g. Storage Blob Data Reader) over broad roles like Contributor, and create a dedicated UAMI per service. You don’t need to add any federated credentials yourself — Porter creates the one mapping your service’s Kubernetes service account to this identity on the next deploy.

​
Step 2 — Attach the identity to your service

In the Porter dashboard, open the service you want to grant access to and scroll to the Azure Managed Identity Connection section. Toggle the connection on and enter the managed identity name and resource group: Azure Managed Identity Connection UI On the next deploy, Porter creates the federated identity credential on the UAMI. From your application code, use DefaultAzureCredential from the Azure SDK and Azure will resolve credentials automatically — no client secrets, no certificates.
If you manage your app config as code, you can declare the same connection in porter.yaml:
services:
  - name: api
    # ...
    connections:
      - type: azureManagedIdentity
        identityName: my-app-api-identity
        resourceGroup: my-resource-group
See Connections in porter.yaml for the full schema.

​
GCP

Workload identity support for GCP is in development. The equivalent flow on GKE — binding a Porter service to a Google service account via Workload Identity Federation — is not yet generally available. If you’d like this enabled for your project, reach out to Porter support and we’ll work with you to get early access.