Why use AWS IAM Roles Anywhere and how to use it from on-premises with best security practices ?

Sudhir Kumar
5 min readDec 6, 2023

--

In below post, I will be covering topics related to why use IAM Roles Anywhere, components, Security best practices, Service Control Policy and multiple methods to establish this trust from on-premises and AWS i.e. On-premises PKI using Vault with ADCS (Active Directory Certificate Service) to generate x.509 certificates OR AWS Private Certificate Manager.

Why use IAM Roles Anywhere ?

IAM Roles Anywhere Components ?

Best Security Practices ?

Service Control Policy ?

Monitoring/High availability (metrics) ?

Methods to establish trust between AWS services (AWS Private Cert Manager OR On-premises PKI/Certificate Authority?

Why use IAM Roles Anywhere ?

Traditionally, for on-premises workload we have to create IAM static credentials for automation / programs. You can use AWS Identity and Access Management Roles Anywhere to obtain temporary security credentials in IAM for workloads that run outside of AWS. It means you don’t need to manage long-term credentials for workloads running outside of AWS.

Pros:

  • No need to create/rotate IAM access/secret keys every 90 days OR whenever employee leaves org OR changes team. In legacy systems, it’s hard to follow secrets rotation practices and sometimes we keep using same IAM secrets for years.
  • You can set credentials session duration from 15 mins — 60 mins.
  • CloudTrail captures all API calls for IAM Roles Anywhere as events.
  • Setup VPC Endpoint for IAM Roles anywhere and configure on-premises DNS to resolve endpoint DNS to private IP address. By achieving this, we make sure that even with trust anchor ARN, private key etc. — aws_signing_helper program won’t be able to generate credentials from internet. You need to be in private network connected via IPSEC or Directconnect to VPC Endpoint service.

Cons:

  • Operational overhead: IAM Roles anywhere/ Trust anchor is not a global construct like IAM but a regional service.

IAM Roles Anywhere Components:

  • Trust Anchor : Establish trust between IAM Roles Anywhere and your CA. Your CA can be either AWS Private Certificate Authority (PCA) OR on-premises Root CA Certificate).
  • Roles : IAM Role Anywhere can assume this role (with specific permissions) and deliver temporary credentials.
  • Profiles : Profiles are predefined set of permissions that can apply to roles used by workload that authenticate with IAM Roles anywhere. You can add Role under Profile and also add optional Session Policy which act like permission boundary.

Best Security Practices :

SCP (Service Control Policy) for IAM Roles Anywhere:

Creating SCP for IAM Roles anywhere is a good security practice as it’s an entry point to obtain AWS short term credentials using x.509 certificates.

Which SCP ?

  • Create SCP and deny all IAM users/roles to create Trust Anchor. Allow only certain superadmin roles (just in time access) that can be accessed via approval workflow OR under certain condition.
  • Create SCP to deny edit trust relationship policy in which we mention all conditional statements.

Additional Security :

  • Create VPC Endpoint Service for IAM Roles Anywhere and add a condition in IAM Role trust policy to allow only that VPCE ID along with other conditional keys.
  • IP whitelisting in IAM policy.
  • As all logs present in cloudtrail, it already includes Guardduty that can help with anomaly detection; example -> running signing helper program with Tor IP as source.

Monitoring:

  • This is highly available but regional service. You can set it up in atleast 2 regions for mission critical applications and can use it in active/passive mode.
  • Monitor all Cloudtrail logs to backtrack issues.
  • You can monitor “CreateSession” event for “Failure” metric i.e. fails to return credentials to the user. You can also monitor it for “Success” metric to identify any anomaly detection.
  • Monitor Certificate expiry date.
  • Setup Alerting on above critical metrics.

Two methods to establish trust between AWS services using mutual TLS (Transport Layer Security). Mutual TLS involves both parties presenting certificates to each other to establish trust.

  1. AWS Private Certificate Manager:

AWS Private Certificate Manager is a global construct and first you need to create Private CA (Certificate Authority). This involves specifying the root domain for the private CA, configuring CRL (Certificate Revocation List), etc. You can also share Private CA with all member accounts as it’s costly.

Afterwards, you can create Private Cert, request it and mention Common-name etc. After cert approval (domain validation) you can start using it in Trust Anchor.

Under Trust relationship — you can add cert info with condition “aws:RequesterCACertificateArn” to trust it. Now, your IAM role should trust private certificate issued by your private CA.

2. On-premises PKI/Root Certificate Authority:

Pre-requisite : You already have on-premises Vault Setup and integrated with ADCS (Active Directory Certificate Services).

Vault applies a dynamic secret approach to X.509 public key infrastructure (PKI) certificates, acting as a signing intermediary to generate short-lived certificates.Vault provides a secure/auditable way to manage secrets.

In this approach, we are moving away from AWS PCA security to on-premises PKI/CA and make sure that we have restrictions in place to create certs with “CN/Common Name” to only assigned groups else anyone with access to generate certificates with desired Common Name will be able to generate credentials in AWS.

Convert RSA to PEM format using : openssl rsa -in privatersa.key -out priv.key before using signing helper program.

How to generate short term credentials via cli:

Usage: ./aws_signing_helper credential-process \ — certificate [ — endpoint] [ — region] [ — intermediates] — private-key — profile-arn — role-arn [ — session-duration] — trust-anchor-arn [ — with-proxy] [ — no-verify-ssl]

  • You can also add above command in profile under ~/.aws/config :

[profile iamrolesanywhere]

credential_process = ./aws_signing_helper credential-process \ — certificate [ — endpoint] [ — region] [ — intermediates] — private-key — profile-arn — role-arn [ — session-duration] — trust-anchor-arn [ — with-proxy] [ — no-verify-ssl]

Afterwards, you can use ->

aws s3 ls — profile iamrolesanywhere

to use it directly via command line.

If this post was helpful, please click the clap 👏 button below a few times to show your support for the author 👇

--

--

Sudhir Kumar
Sudhir Kumar

Written by Sudhir Kumar

Working as Cloud lead/Architect with security mindset.

No responses yet