Full Report
In the earlier posts in this series, we showed not only how to get rid of unused access keys, but also how to minimize risk by applying a least-privilege strategy. In this final post, we’ll at last get into the discussion of alternative solutions to using access keys.
Analysis Summary
# Best Practices: Eliminating Long-Lived AWS Access Keys
## Overview
These practices provide alternatives and guidance for eliminating the reliance on long-lived IAM User Access Keys by employing short-lived, system-bound credentials, primarily focusing on cross-cloud interactions and workloads outside of native AWS compute environments (on-premises/other clouds).
## Key Recommendations
### Immediate Actions
1. **Prioritize Short-Lived Credentials:** Immediately move away from using long-lived IAM access keys for any workload needing cross-cloud access or on-premises access, favoring methods that issue temporary credentials.
2. **Review Third-Party Integrations for OIDC:** For compute resources in other cloud providers (like GCP or Azure) or services like GitHub Actions requiring AWS access, immediately implement or verify OpenID Connect (OIDC) federation instead of using static keys.
### Short-term Improvements (1-3 months)
1. **Implement Granular OIDC Trust Policies:** When configuring OIDC trust policies for third-party services, ensure extremely precise conditions (e.g., using the `sub` condition to specify the exact `GitHubOrg/GitHubRepo`) to prevent unauthorized assumption of the IAM role by unrelated entities.
2. **Evaluate IAM Roles Anywhere for On-Premises Access:** For servers or physical devices needing AWS access, start the evaluation and pilot implementation of AWS IAM Roles Anywhere as a replacement for access keys, leveraging certificate-based authentication.
3. **Pilot AWS Systems Manager Hybrid Activation:** Test Systems Manager hybrid activation for on-premises servers, leveraging its built-in risk mitigation features like limited-time, single-use activation codes and device fingerprinting.
### Long-term Strategy (3+ months)
1. **Integrate Hardware Security Modules (TPMs):** Plan infrastructure upgrades or architecture changes to utilize hardware security devices (like TPMs) to store private keys for signing operations, leveraging PKCS11 standards (once supported via tooling updates) with IAM Roles Anywhere or similar mechanisms.
2. **Standardize on Credential Vending:** Move away from storing any form of persistent credential (certificates or fingerprints) on disk for on-premises workloads. Implement credential-process vending solutions where possible, accessing temporary credentials on demand, even if only secured against arbitrary file reads.
3. **Phased Migration from Certificates/Fingerprints to Disk:** For IAM Roles Anywhere and Systems Manager, develop and execute a strategy to minimize on-disk storage of session credentials or system fingerprints, relying on secure processes (potentially via evolving PKCS11 support) instead.
## Implementation Guidance
### For Small Organizations
- **Focus on OIDC:** Start by migrating all third-party integrations (CI/CD, scripts) to use OIDC federation, as this is often the quickest path to eliminating hardcoded keys in source control or configuration files.
- **Start with SSM Hybrid Activation:** For on-premises servers, Systems Manager hybrid activation provides a simpler initial setup utilizing device characteristics and time-bound codes, offering significant risk reduction immediately.
### For Medium Organizations
- **Establish PKI Management Policy:** If adopting IAM Roles Anywhere, establish clear governance and management procedures for the Public Key Infrastructure (PKI) supporting the certificates used for authentication.
- **Leverage Conditional Access:** Utilize the flexibility of IAM policy conditions associated with the certificates in IAM Roles Anywhere for granular, per-machine or per-context authentication policy enforcement for non-AWS compute.
### For Large Enterprises
- **Develop Custom PKCS11 Solutions:** Actively track or contribute to efforts (like open PRs) to enable PKCS11 support in AWS tooling, allowing enterprise-level hardware security key management (e.g., YubiKeys or internal HSMs) to handle signing operations securely for both Roles Anywhere and potentially SSM integration.
- **Inventory and Remediate Legacy Access:** Conduct a comprehensive audit to identify all hosts using static AWS credentials and categorize them for migration strategy (OIDC for cloud-to-cloud, Roles Anywhere/SSM for on-prem).
## Configuration Examples
### IAM Role Trust Policy (Conceptual OIDC Example)
The trust policy for an IAM role assuming identity from an external provider (e.g., GitHub Actions) **must** include precise conditions:
json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::ACCOUNT_ID:oidc-provider/provider.server.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"www.amazon.com:iss": "https://accounts.google.com", // Example issuer
"token.actions.githubusercontent.com:sub": "repo:ORGANIZATION/REPOSITORY:ref:refs/heads/main" // CRITICAL: Restrict by specific repo/branch
}
}
}
]
}
*Note: Configuration details for setting up the OIDC provider and the specific `Condition` keys depend on the identity provider.*
## Compliance Alignment
- **NIST SP 800-57 Part 1:** Encourages cryptographic key lifecycle management, aligning with certificate-based auth over static keys.
- **CIS Benchmarks (Cloud Specific):** Aligns with goals to eliminate root/static user credentials in favor of IAM roles and temporary mechanisms.
- **ISO 27001/27002 (A.9 Access Control):** Reduces reliance on user-managed secrets, favoring system-bound, short-lived authentication methods.
## Common Pitfalls to Avoid
1. **Overly Broad OIDC Conditions:** Failing to include specific conditions like `sub` in OIDC policies, which allows *anyone* using the third-party service to assume the role.
2. **Storing IAM Roles Anywhere Certificates on Disk:** Treating the authentication certificate for IAM Roles Anywhere like an access key by saving it insecurely on disk or checking it into source control.
3. **Ignoring Device Fingerprints:** Underestimating the value of device fingerprinting in Systems Manager hybrid activation as a mechanism to tie access to a specific physical host.
4. **Treating Certificates as Permanent:** Assuming that a rotated certificate in IAM Roles Anywhere inherently solves lifecycle risk; mechanisms must still be in place (like short-lived session tokens) to limit credential exposure time.
## Resources
- **AWS IAM Documentation:** Refer to official AWS guides for creating OIDC federation roles.
- **GitHub Documentation:** Check specific documentation for configuring OpenID Connect integration with AWS Actions.
- **IAM Roles Anywhere Documentation (AWS):** Review the official guides for setting up certificate-based trust.
- **Systems Manager Hybrid Activation Guide (AWS):** Use documentation to set up activation codes and understand the fingerprinting process for on-premises instances.
- **`rolesanywhere-credential-helper` (GitHub):** Tooling provided by AWS for certificate handling.
- **`cloudkey` (GitHub, Aidan Steele):** Example open-source project demonstrating leveraging hardware security for certificate signing operations.