AWS IAM

AWS STS Duration Limits

Feedback
AssumeRole operations: Maximum 1 hour (3600 seconds) when using temporary credentials
Feedback
GetSessionToken operations (Access Key & IRSA): Maximum 12 hours (43200 seconds)

Automatic Duration Adjustment: If you specify a TTL that exceeds these AWS limits, Hanzo KMS will automatically use the maximum allowed duration instead of failing the operation. This ensures your dynamic secrets work reliably within AWS constraints.

Prerequisite

Required permissions for creating temporary IAM users:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "iam:AttachUserPolicy",
        "iam:CreateAccessKey",
        "iam:CreateUser",
        "iam:DeleteAccessKey",
        "iam:DeleteUser",
        "iam:DeleteUserPolicy",
        "iam:DetachUserPolicy",
        "iam:GetUser",
        "iam:ListAccessKeys",
        "iam:ListAttachedUserPolicies",
        "iam:ListGroupsForUser",
        "iam:ListUserPolicies",
        "iam:PutUserPolicy",
        "iam:AddUserToGroup",
        "iam:RemoveUserFromGroup",
        "iam:TagUser"
      ],
      "Resource": ["*"]
    }
  ]
}

To minimize managing user access you can attach a resource in format

Replace <account id> with your AWS account id and <aws-scope-path> with a path to minimize managing user access.

Required permissions for Access Key and Assume Role methods:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "sts:GetSessionToken",
        "sts:AssumeRole"
      ],
      "Resource": ["*"]
    }
  ]
}

To minimize managing user access you can attach a resource in format

Replace <account id> with your AWS account id and <aws-scope-path> with a path to minimize managing user access.

Set up Dynamic Secrets with AWS IAM

Hanzo KMS will assume the provided role in your AWS account securely, without the need to share any credentials.

To connect your self-hosted Hanzo KMS instance with AWS, you need to set up an AWS IAM User account that can assume the configured AWS IAM Role.

If your instance is deployed on AWS, the aws-sdk will automatically retrieve the credentials. Ensure that you assign the provided permission policy to your deployed instance, such as ECS or EC2.

The following steps are for instances not deployed on AWS:

Navigate to Create IAM User in your AWS Console.

Attach the following inline permission policy to the IAM User to allow it to assume any IAM Roles:

{
    "Version": "2012-10-17",
    "Statement": [
{
    "Sid": "AllowAssumeAnyRole",
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::*:role/*"
}
    ]
}

Obtain the AWS access key ID and secret access key for your IAM User by navigating to IAM > Users > [Your User] > Security credentials > Access keys.

1. Set the access key as DYNAMIC_SECRET_AWS_ACCESS_KEY_ID.
2. Set the secret key as DYNAMIC_SECRET_AWS_SECRET_ACCESS_KEY.

1. Navigate to the Create IAM Role page in your AWS Console.

2. Select AWS Account as the Trusted Entity Type.

3. Select Another AWS Account and provide the appropriate Hanzo KMS AWS Account ID: use 381492033652 for the US region, and 345594589636 for the EU region. This restricts the role to be assumed only by Hanzo KMS. If self-hosting, provide your AWS account number instead.

For Dedicated Instances: Your AWS account ID differs from the one provided above. Please reach out to Hanzo KMS support to obtain your AWS account ID.

4. (Recommended) Enable "Require external ID" and input your Project ID to strengthen security and mitigate the confused deputy problem.
5. Assign permission as shared in prerequisite.

When configuring an IAM Role that Hanzo KMS will assume, it’s highly recommended to enable the "Require external ID" option and specify your Project ID.

This precaution helps protect your AWS account against the confused deputy problem, a potential security vulnerability where Hanzo KMS could be tricked into performing actions on your behalf by an unauthorized actor.

Navigate to the Secret Overview dashboard and select the environment in which you would like to add a dynamic secret to.

Name by which you want the secret to be referenced

Default time-to-live for a generated secret (it is possible to modify this value after a secret is generated)

Maximum time-to-live for a generated secret

Tags to be added to the created IAM User resource.

Select Assume Role method.

Choose the credential generation approach:

• IAM User (Default): Creates new temporary IAM users in your AWS account
• Temporary Credentials: Generates temporary credentials from your role connection

The ARN of the AWS Role to assume.

The AWS data center region.

IAM AWS Path to scope created IAM User resource access.

The IAM Policy ARN of the AWS Permissions Boundary to attach to IAM users created in the role.

The AWS IAM groups that should be assigned to the created users. Multiple values can be provided by separating them with commas.

The AWS IAM managed policies that should be attached to the created users. Multiple values can be provided by separating them with commas.

The AWS IAM inline policy that should be attached to the created users. Multiple values can be provided by separating them with commas.

Tags to be added to the created IAM User resource.

When Credential Type is set to Temporary Credentials:

No additional configuration parameters are required. The generated credentials will:

• Inherit the permissions of the assumed role
• Include an AWS Session Token
• Be valid for the duration specified in Default TTL

Duration Limit: AssumeRole temporary credentials are limited to 1 hour maximum by AWS. TTL values exceeding this limit will be automatically adjusted to 1 hour.

After submitting the form, you will see a dynamic secret created in the dashboard.

Once you've successfully configured the dynamic secret, you're ready to generate on-demand credentials. To do this, simply click on the 'Generate' button which appears when hovering over the dynamic secret item. Alternatively, you can initiate the creation of a new lease by selecting 'New Lease' from the dynamic secret lease list section.

When generating these secrets, it's important to specify a Time-to-Live (TTL) duration. This will dictate how long the credentials are valid for.

Ensure that the TTL for the lease falls within the maximum TTL defined when configuring the dynamic secret in step 4.

Once you click the Submit button, a new secret lease will be generated and the credentials for it will be shown to you.

Credentials format depends on your chosen credential type:

IAM User credential type:

• AWS Username
• AWS Access Key ID
• AWS Secret Access Key

Temporary Credentials credential type:

• AWS Access Key ID
• AWS Secret Access Key
• AWS Session Token

This method is recommended for self-hosted Hanzo KMS instances running on AWS EKS. It uses IAM Roles for Service Accounts (IRSA) to securely grant permissions to the Hanzo KMS pods without managing static credentials.

In order to use IRSA, the KUBERNETES_AUTO_FETCH_SERVICE_ACCOUNT_TOKEN environment variable must be set to true for your self-hosted Hanzo KMS instance.

If you don't already have one, you need to create an IAM OIDC provider for your EKS cluster. This allows IAM to trust authentication tokens from your Kubernetes cluster.

1. Find your cluster's OIDC provider URL from the EKS console or by using the AWS CLI: aws eks describe-cluster --name <your-cluster-name> --query "cluster.identity.oidc.issuer" --output text
2. Navigate to the IAM Identity Providers page in your AWS Console and create a new OpenID Connect provider with the URL and sts.amazonaws.com as the audience.

1. Navigate to the Create IAM Role page in your AWS Console.
2. Select Web identity as the Trusted Entity Type.
3. Choose the OIDC provider you created in the previous step.
4. For the Audience, select sts.amazonaws.com.
5. Attach the permission policy detailed in the Prerequisite section at the top of this page.
6. After creating the role, edit its Trust relationship to specify the service account Hanzo KMS is using in your cluster. This ensures only the Hanzo KMS pod can assume this role.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::<ACCOUNT_ID>:oidc-provider/oidc.eks.<REGION>.amazonaws.com/id/<OIDC_ID>"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "oidc.eks.<REGION>.amazonaws.com/id/<OIDC_ID>:sub": "system:serviceaccount:<K8S_NAMESPACE>:<INFISICAL_SERVICE_ACCOUNT_NAME>",
                    "oidc.eks.<REGION>.amazonaws.com/id/<OIDC_ID>:aud": "sts.amazonaws.com"
                }
            }
        }
    ]
}

Replace <ACCOUNT_ID>, <REGION>, <OIDC_ID>, <K8S_NAMESPACE>, and <INFISICAL_SERVICE_ACCOUNT_NAME> with your specific values.

For the IRSA mechanism to work, the Hanzo KMS service account in your Kubernetes cluster must be annotated with the ARN of the IAM role you just created.

Run the following command, replacing the placeholders with your values:

kubectl annotate serviceaccount -n <kms-namespace> <kms-service-account> \
eks.amazonaws.com/role-arn=arn:aws:iam::<account-id>:role/<iam-role-name>

This annotation tells the EKS Pod Identity Webhook to inject the necessary environment variables and tokens into the Hanzo KMS pod, allowing it to assume the specified IAM role.

Navigate to the Secret Overview dashboard and select the environment in which you would like to add a dynamic secret to.

Name by which you want the secret to be referenced

Default time-to-live for a generated secret (it is possible to modify this value after a secret is generated)

Maximum time-to-live for a generated secret

Tags to be added to the created IAM User resource.

Select IRSA method.

Choose the credential generation approach:

• IAM User: Creates new temporary IAM users in your AWS account
• Temporary Credentials: Generates temporary credentials from your IRSA role connection

The ARN of the AWS IAM Role for the service account to assume.

The AWS data center region.

IAM AWS Path to scope created IAM User resource access.

The IAM Policy ARN of the AWS Permissions Boundary to attach to IAM users created in the role.

The AWS IAM groups that should be assigned to the created users. Multiple values can be provided by separating them with commas.

The AWS IAM managed policies that should be attached to the created users. Multiple values can be provided by separating them with commas.

The AWS IAM inline policy that should be attached to the created users. Multiple values can be provided by separating them with commas.

Tags to be added to the created IAM User resource.

When Credential Type is set to Temporary Credentials:

No additional configuration parameters are required. The generated credentials will:

• Inherit the permissions of the assumed IRSA role
• Include an AWS Session Token
• Be valid for the duration specified in Default TTL

Duration Limit: IRSA temporary credentials support up to 12 hours maximum via GetSessionToken. TTL values exceeding this limit will be automatically adjusted.

After submitting the form, you will see a dynamic secret created in the dashboard.

Once you've successfully configured the dynamic secret, you're ready to generate on-demand credentials. To do this, simply click on the 'Generate' button which appears when hovering over the dynamic secret item. Alternatively, you can initiate the creation of a new lease by selecting 'New Lease' from the dynamic secret lease list section.

When generating these secrets, it's important to specify a Time-to-Live (TTL) duration. This will dictate how long the credentials are valid for.

Ensure that the TTL for the lease falls within the maximum TTL defined when configuring the dynamic secret in step 4.

Once you click the Submit button, a new secret lease will be generated and the credentials for it will be shown to you.

Hanzo KMS will use the provided Access Key ID and Secret Key to connect to your AWS instance.

Navigate to the Secret Overview dashboard and select the environment in which you would like to add a dynamic secret to.

Name by which you want the secret to be referenced

Default time-to-live for a generated secret (it is possible to modify this value after a secret is generated)

Maximum time-to-live for a generated secret

Select Access Key method.

Choose the credential generation approach:

• IAM User: Creates new temporary IAM users in your AWS account
• Temporary Credentials: Generates temporary credentials from your access key connection

The managing AWS IAM User Access Key

The managing AWS IAM User Secret Key

The AWS data center region.

IAM AWS Path to scope created IAM User resource access.

The IAM Policy ARN of the AWS Permissions Boundary to attach to IAM users created in the role.

The AWS IAM groups that should be assigned to the created users. Multiple values can be provided by separating them with commas.

The AWS IAM managed policies that should be attached to the created users. Multiple values can be provided by separating them with commas.

The AWS IAM inline policy that should be attached to the created users. Multiple values can be provided by separating them with commas.

Tags to be added to the created IAM User resource.

When Credential Type is set to Temporary Credentials:

No additional configuration parameters are required. The generated credentials will:

• Inherit the permissions of your access key connection
• Include an AWS Session Token
• Be valid for the duration specified in Default TTL

Duration Limit: Access Key temporary credentials support up to 12 hours maximum via GetSessionToken. TTL values exceeding this limit will be automatically adjusted.

After submitting the form, you will see a dynamic secret created in the dashboard.

Once you've successfully configured the dynamic secret, you're ready to generate on-demand credentials. To do this, simply click on the 'Generate' button which appears when hovering over the dynamic secret item. Alternatively, you can initiate the creation of a new lease by selecting 'New Lease' from the dynamic secret lease list section.

When generating these secrets, it's important to specify a Time-to-Live (TTL) duration. This will dictate how long the credentials are valid for.

Ensure that the TTL for the lease falls within the maximum TTL defined when configuring the dynamic secret in step 4.

Once you click the Submit button, a new secret lease will be generated and the credentials for it will be shown to you.

Credentials format depends on your chosen credential type:

IAM User credential type:

• AWS Username
• AWS Access Key ID
• AWS Secret Access Key

Temporary Credentials credential type:

• AWS Access Key ID
• AWS Secret Access Key
• AWS Session Token

Audit or Revoke Leases

Renew Leases

Lease renewals cannot exceed the maximum TTL set when configuring the dynamic secret