Managed (AKA passthrough) identity for all Seqera-supported infra providers
acknowledged
Andrew Dawson
We’d love to see Seqera Platform support cloud identity passthrough, allowing pipelines to securely access cloud resources (like storage, compute, secrets) using native identity mechanisms from AWS, Azure, and GCP — without needing to manage long-lived credentials. (Seqera Platform already supports this for HPC).
This would allow access to cloud services to be governed directly by cloud IAM policies, improving both security and enterprise integration.
Why this matters
Today, jobs typically authenticate to cloud services using infrastructure-level credentials (e.g., an IAM role or service principal attached to the compute environment). These credentials are:
- Shared across users
- Often over-permissioned
- Not user-aware — cloud services can’t tell who requested access
This limits enterprises from applying their existing IAM policies and can create operational or audit complexity.
✅ What we’re asking for
Enable Seqera Platform to support cloud-native, credential-less authentication, such as:
- AWS: IAM Roles with identity federation (e.g., via IAM Identity Center or OIDC)
- Azure: System- and user-assigned Managed Identities
- GCP: Workload Identity Federation tied to user or workspace context
This would allow:
- Per-user or per-pipeline IAM role/identity selection
- Fine-grained access controls to cloud resources, managed entirely in the cloud provider’s IAM system
- Removal of static secrets (like service principal keys or access tokens)
Andrew Dawson
acknowledged
Andrew Dawson
Merged in a post:
Seqera Platform can use Azure managed identities as a credential for enterprise installations
Adam Talbot
Currently, Seqera Platform can authenticate to Azure using a service principal. While fine, this requires long-lived keys.
An enterprise (on premise) installation of Seqera Platform could use a managed identity for credential-less authentication. This would be more secure and provide significantly more security but is only available when running on an Azure hosted system.
This is supported on AWS using the equivalent IAM roles: https://docs.seqera.io/platform/24.2/enterprise/advanced-topics/use-iam-role
Azure supports a resource having >1 Managed Identity attached, therefore there are two ways this could work:
- Add a system assigned managed identity, users would still need to add Azure "credentials" for the Azure Storage and Batch account name, however they would not need to add any service principal details.
- Using multiple user-assigned managed identities, a user would still need to add Azure "credentials" for the Azure Storage and Batch account name, however they would also need to specify which managed identity they would like to use to authenticate
1 is easier to configure and more secure, however 2 provides far more control for system administrators. It might require more work on the user end to know which ID to use.
Andrew Dawson
Merged in a post:
Managed (AKA passthrough) identity: AWS resources (S3, Batch, EKS)
Andrew Dawson
Today, Seqera supports configuring an AWS IAM role (via IRSA or instance profiles) for jobs running on AWS Batch or EKS. This lets the job containers access AWS services like S3 or Secrets Manager without long-lived credentials.
However, this IAM role is shared across all users, meaning:
- You have to over-permission it to cover all use cases
- You lose per-user authorization (e.g., 'user 1' should have access to 'bucket X', 'user 2' shouldn’t)
- Any access control managed in AWS gets duplicated or bypassed in Seqera
We’d like to see support for true AWS identity passthrough, where:
- A user’s identity in Seqera maps to a specific AWS IAM identity (via IAM Identity Center or OIDC)
- AWS handles the authorization natively, based on its policies
- Jobs fail if the user doesn’t have access — just like they already do in HPC environments with managed identities
We understand this introduces new failure modes (e.g., access denied errors), and would expect:
- Clear, user-friendly error messages (e.g., “You don’t have permission to access S3 bucket X — contact your AWS admin.”)
- Preflight checks or validation where possible
This would bring cloud environments in line with how managed identity works today on HPC, and give enterprises tighter control and better auditability.
Andrew Dawson
Merged in a post:
GCP: Support for Workload Federated Identity
P
Profound Angelfish
We've always had to create service account keys for authentication of workloads against Google Batch/GLS.
This isn't ideal due to service account keys being highly sensitive credentials, and the difficulty in rotating keys and updating them in Seqera Platform / Tower.
I'd love to see Seqera Platform offer support for Google's Workload Federated ID, which will mean no longer having to create service account keys and upload them as credentials. I see you are rolling out something similar for Azure Entra (beta) in Seqera Platform?
This will allow us to continue to adhere to SecOps best practices, and ensure the risk of leaked keys is kept to a minimum.