Back to articles
December 31, 2024

Policy and Standards Automation (2)

AWS Secrets Manager

Troubleshoot Cross-Account Secret Sharing

  • When Sharing credentials cross-account
    • cross-account access to Secrets Manager must be configured
  • When secret rotation is configured, it causes the secret to rotate once as soon as you store the secret.
    • this could cause the old credential to not be useable after the initial rotation, especially for apps not using the Secrets Manager
  • The AWS credentials used to call Secrets Manager from the application need to have the 'secretsmanager:DescribeSecret' permission
  • GetSecretValue has an optional VersionStage OR VersionId parameter
    • these specify a specific secret version
    • default is VersionStage: AWSCURRENT
  • To retrieve a previous version of a secret, pass the SecretId and VersionStage: AWSPREVIOUS
  • If you always want the current secret, don't specify VersionStage or VersionId at all
    • default is VersionStage AWSCURRENT

Rotate Secrets for non-RDS Database

  • if database is not controlled by you
    • you may need an additional account to configure to auth to the database
  • you might see client sign-on failure due to time lag:
    • between change of actual password and the change in the corresponding secret that tells the client which password to use (VersionId or VersionStage)

Steps of the Secrets Manager Lambda Function

  • When you specify a secret for a supported RDS database, a standard Lambda function is used to rotate the secret. Steps in that Lambda function are:
    • createSecret Step
      • Staging Label is set to AWSPENDING
    • setSecret Step
      • either: changes secret labeled AWSPENDING
      • or: creates new credentials to match the requested ones
    • testSecret Step
      • Lambda uses AWSPENDING secret to attempt login to your secured resource
      • you can configure read-only or read-write access, depending on requirements
    • finishSecret Step
      • updates label, moves AWSCURRENT to new password
      • sets AWSPREVIOUS on the 'old current' password
      • removes label from 'old previous', making it available for deletion
    • You can create a second set of credentials with permissions to change the password, or create new credentials.
      • This is the 'master' secret
      • Secrets Manager stores the master secret separately
      • Lambda function uses the master secret to rotate/create other credentials

Jira Setup on AWS

  • Single VPC with Public and Private subnets
    • each subnet should be in a different Availability Zone
  • NAT GW's in public subnets
    • routing to allow outbound Internet access from private subnet
  • Bastion host in single ASG to allow ssh access to EC2 instances in private subnet
  • Internal ELB load balancing between Jira instances
    • also SSL termination reverse proxy on the ELB
    • ALB can be used
  • Jira applications installed on EC2 instances in private subnet
    • joined to an AutoScalingGroup ASG
  • Jira requires a relational DB
    • Aurora PostgreSQL is supported
  • Jira uses a shared file system to store artifacts
    • AWS EFS is supported
Loading comments...