This guide outlines best practices for deploying the Akeyless Gateway following AWS security standards, with a primary focus on managing secrets cross-account AWS environments. It highlights recommended deployment models, their trade-offs, and how to manage Dynamic Secrets, Rotated Secrets, and the Universal Secrets Connector using only IAM roles without relying on long-lived credentials.

At its core, the Akeyless Gateway serves as a secure execution layer that facilitates a range of operations from cryptographic processing to secure network access on behalf of the Akeyless SaaS platform, without exposing sensitive workloads to the public network.

When managing environments across multiple AWS accounts, the key requirement is to establish a consistent and automated approach for deploying and operating the Akeyless Gateway across the organization. This ensures reliable configuration, centralized control, and seamless integration of Gateway capabilities throughout all AWS member accounts.

👍

AWS Partner

Akeyless is an official AWS partner recognized with the Security ISV Competency.

How Akeyless Gateway authenticates using IAM

AWS compute resources can authenticate directly to Akeyless using supported identity mechanisms. These include:
EC2 instances, Lambda functions, ECS (Elastic Container Service) tasks, EKS (Elastic Kubernetes Service) pods (if using IAM roles for service accounts)
These resources use AWS IAM roles to obtain temporary credentials, which Akeyless uses to validate their identity.

When the Gateway is running on such a resource, it utilizes the existing identity to authenticate to Akeyless SaaS services.

How is this authentication implemented securely?

Akeyless supports IAM-based authentication through its AWS IAM Auth method, which leverages AWS’s native STS (Security Token Service) and identity documents. The process is as follows:

1. The AWS resource retrieves temporary credentials from its IAM role.
2. The resource sends these credentials to Akeyless using the auth API endpoint
3. Akeyless validates the request using AWS STS by calling the GetCallerIdentity API to verify the authenticity and identity of the requester. This exchange does not expose long-term credentials and relies on short-lived tokens, ensuring secure communication. This secure flow avoids needing to manage static secrets or access keys within AWS services.

How Akeyless Target should be used

All deployment patterns are working without any AWS long-lived credentials and should be set only using AWS roles leveraging the Akeyless AWS Target via cloud ID option that uses the AWS role.

When using an AWS Targetwith the Gateway Cloud ID option, the Akeyless Gateway leverages the IAM role associated with the underlying compute service it’s running on, such as a service account role in EKS or an instance profile role attached to an EC2 instance. To extend access beyond the AWS account the Gateway is running on, the Target can be explicitly set with a role ARN with External ID, overriding the default identity behavior and allowing secure, cross-account operations. This means a single Target can be shared across multiple Gateways, with each Gateway operating under the permissions granted to its own associated AWS role.

📘

AWS Configuration and credential precedence

Akelyess uses AWS official SDK, hence the role that will be used is according to AWS precedence.

Deployment patterns

As the Akelyess Gateway is a light, stateless application, it might be deployed using the following patterns according to your preference while managing an AWS organization with multiple accounts:

• Centralized Gateway: Deploy a single Gateway in a “security-services” or “shared-tools” account. In each member account, create an IAM role that the Gateway can assume, protected with an External ID. Register each role as an AWS Target in Akeyless. Where Dynamic Secrets, Rotated Secrets, USC, etc., will point to that Target. This will end with 1 or more Gateways to manage and monitor, while keeping member accounts isolated.

• Distributed Gateways: Deploy different Gateways in every account. Each Gateway works only on its local AWS account, but is managed from the same Akeyless account.