User-level data permissions
complete
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)
- 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)
Rob Newman
updated the status to
complete
Released in Enterprise
v26.2
and into Cloud in October 2026.Rob Newman
Azure's WIF and STS token exchange does not work the same way as AWS and GCP, and so has been removed from this feature request to a future milestone.
Rob Newman
updated the status to
in progress
M
Michael Tansini
updated the status to
planned
Andrew Dawson
Merged in a post:
File-Level Role-Based Access Control for S3 Buckets
C
Canny AI
I need the ability to provide access to only parts of a dataset within a single S3 bucket without duplicating data. This would allow us to manage a large dataset efficiently and securely by granting access to specific data subsets based on user roles.
Rob Newman
Merged in a post:
Role Assumption for ECR Credentials
Drew DiPalma
I would like the platform to support using role assumption to get ECR credentials, as it would be super handy for our setup.
Rob Newman
Merged in a post:
Support for IAM roles without user credentials
Drew DiPalma
I would like the platform to support IAM roles without requiring user credentials. This would enhance security by allowing us to use IAM roles directly, without the need for long-lived access keys and secret keys.
Rob Newman
Merged in a post:
Add the managed IAM policy AmazonSSMManagedInstanceCore to Instance Role by default
Mark Panganiban
This policy will easily allow the users to access the ec2 instances spawned by head and worker nodes through SSM connect without the need for key pairs.
Andrew Dawson
updated the status to
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.
Load More
→