Long-lived credentials are one of the most persistent security problems in federal cloud programs. Static access keys committed to code repositories, hardcoded passwords in configuration files, shared service account credentials passed between teams — each one is a potential breach vector that compromises the entire system boundary.
Eliminating long-lived secrets in AWS GovCloud is achievable with current tooling. This covers how Rutagon implements zero-secret architecture across CI/CD pipelines, application containers, and infrastructure automation for federal programs.
Why Long-Lived Secrets Are a Compliance Problem
NIST SP 800-53 IA-5 (Authenticator Management) requires that authenticators — including passwords and cryptographic keys — have defined lifetimes, be rotated on schedule, and be revoked when no longer needed. Static AWS IAM access keys violate IA-5 controls because:
- They don't expire without explicit rotation action
- Rotation requires coordinating updates across all consuming systems
- Compromise is difficult to detect because the key provides legitimate access patterns
- They're frequently over-scoped (full account access "for convenience")
CMMC Level 2 control IA.3.083 extends this requirement to the CMMC framework. DFARS 252.204-7012 incident reporting requirements make it critical that compromised credentials can be quickly identified and revoked — which is far harder when credentials are distributed and unknown in scope.
The zero-secret goal: no application or pipeline should hold a long-lived credential at rest. Access should be granted dynamically, scoped to exactly what's needed, and expire automatically.
IRSA: Zero-Credential AWS Access from Kubernetes
IAM Roles for Service Accounts (IRSA) is the foundational primitive for zero-secret application architecture in EKS — including EKS on AWS GovCloud.
IRSA replaces stored IAM credentials with a trust relationship: the Kubernetes service account is annotated with an IAM role ARN, and the OIDC provider on the EKS cluster federates pod identity to AWS IAM. The pod receives short-lived STS credentials automatically — no stored keys.
apiVersion: v1
kind: ServiceAccount
metadata:
name: telemetry-ingest
namespace: production
annotations:
eks.amazonaws.com/role-arn: arn:aws-us-gov:iam::123456789:role/telemetry-ingest-roleThe IAM role's trust policy restricts assumption to this specific service account in this specific namespace — not to all pods in the cluster:
{
"Principal": {
"Federated": "arn:aws-us-gov:iam::123456789:oidc-provider/..."
},
"Condition": {
"StringEquals": {
"oidc-provider/...:sub": "system:serviceaccount:production:telemetry-ingest"
}
}
}The application uses the standard AWS SDK — no code changes required. Credentials are rotated automatically every 15 minutes by default. CloudTrail logs show the actual service account assumption, providing attribution that static keys can't offer.
For FedRAMP IA-5 compliance: IRSA credentials are short-lived (meeting the "defined lifetime" requirement) and automatically revoked when the pod terminates (meeting the "revocation" requirement). IAM role assignments are infrastructure-as-code, auditable in version control.
AWS Secrets Manager for Application Secrets
For application secrets that can't be eliminated with IRSA (database passwords, third-party API keys, encryption keys), AWS Secrets Manager provides centralized secret storage with automatic rotation and fine-grained access control.
Automatic rotation: Secrets Manager supports automatic rotation via Lambda functions for RDS databases (built-in rotation), and custom rotation functions for other secret types. Rutagon implements automatic rotation for all database credentials on government programs — typically 30-day rotation cycles, configurable shorter for higher-classification requirements.
Pod access via IRSA: Pods retrieve secrets at startup using IRSA credentials — the pod never stores the secret at rest, just retrieves it at initialization. The Kubernetes External Secrets Operator (ESO) automates this pattern:
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: db-credentials
namespace: production
spec:
refreshInterval: 1h
secretStoreRef:
name: aws-secretsmanager
kind: ClusterSecretStore
target:
name: db-credentials
creationPolicy: Owner
data:
- secretKey: password
remoteRef:
key: production/db/credentials
property: passwordESO fetches the secret from Secrets Manager and injects it as a Kubernetes Secret, refreshing it on the defined interval. Applications never call Secrets Manager directly — they consume Kubernetes Secrets as environment variables or volume mounts.
Audit trail: Every Secrets Manager read is recorded in CloudTrail with the IAM principal that accessed it. This provides the access audit trail required by NIST AU-9 (Protection of Audit Information) and AU-12 (Audit Record Generation).
AWS Systems Manager Parameter Store
For configuration values and non-sensitive parameters that still shouldn't be embedded in code, SSM Parameter Store provides a governed configuration store integrated with IAM.
SecureString parameters in Parameter Store are encrypted with KMS — suitable for lower-sensitivity secrets where Secrets Manager's automatic rotation and more granular access controls aren't needed. Rutagon uses Parameter Store for environment-specific configuration (endpoints, feature flags, non-secret configuration) and Secrets Manager for actual credentials.
Eliminating Secrets from CI/CD Pipelines
CI/CD pipelines are a common source of long-lived credential exposure — pipelines require AWS credentials to deploy, and those credentials are often stored as environment variables in CI platforms.
GitHub Actions with OIDC: GitHub Actions supports OIDC federation to AWS IAM. The workflow authenticates directly to AWS without stored secrets:
- name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: arn:aws-us-gov:iam::123456789:role/github-actions-deploy
aws-region: us-gov-west-1AWS IAM role conditions restrict which GitHub organization, repository, and branch can assume the role. A feature branch can't assume the production deployment role — only the main branch can.
For GitLab CI (common on DoD programs using Platform One), the same pattern applies using GitLab's OIDC JWT federation.
Result: Zero long-lived AWS credentials stored in CI platforms. The pipeline generates short-lived credentials on every run with full CloudTrail attribution.
Related: OIDC Eliminating Secrets from AWS Pipelines | Zero Trust: Eliminating Long-Lived Credentials | Managed DevSecOps Pipeline for Prime Delivery
Frequently Asked Questions
What is IRSA and why does it matter for GovCloud programs?
IRSA (IAM Roles for Service Accounts) allows EKS pods to assume IAM roles without storing any access keys. The pod receives short-lived STS credentials automatically via OIDC federation. For GovCloud programs, IRSA satisfies NIST IA-5 authenticator management requirements by providing short-lived, automatically rotated, automatically revoked credentials with full CloudTrail attribution.
Can AWS Secrets Manager be used in GovCloud for classified workloads?
AWS Secrets Manager is available in AWS GovCloud (us-gov-west-1, us-gov-east-1) and is included in the FedRAMP High authorization. For IL4 and IL5 programs, it's authorized as a component within the system boundary provided the access policies, KMS CMK encryption, and CloudTrail logging are properly configured. Rutagon documents Secrets Manager components in system boundary diagrams and SSP control narratives.
How do you handle secret rotation for RDS databases in a GovCloud program?
AWS Secrets Manager provides built-in automatic rotation for Aurora and RDS databases via managed Lambda rotation functions. Rutagon configures rotation on a schedule appropriate to the program's security requirements (typically 30–90 days). The rotation function updates both the database password and the secret value in Secrets Manager atomically, and the application refreshes credentials from the External Secrets Operator sync cycle without requiring a restart.
What happens to IRSA credentials when a pod crashes?
When a pod terminates (crash or intentional), the IRSA credentials expire within their STS session duration (default 15 minutes). If the pod restarts, it receives fresh credentials at startup. There's no "credential leakage" from a crashed pod — the credentials were bound to the pod's execution context and have no value after pod termination.
How does eliminating long-lived secrets affect DFARS 252.204-7012 incident response?
Under DFARS 252.204-7012, suspected incidents must be reported to DIBNet within 72 hours. A compromised long-lived IAM access key is very hard to scope — the key may have been used across multiple accounts, sessions, and time periods. A compromised IRSA role assumption is much more contained: the blast radius is limited to the sessions within the short credential lifetime, CloudTrail records every assumption with full attribution, and the role policy limits what can be accessed. Short-lived credentials make incident scope much more bounded and reportable.