A deep dive into AWS Systems Manager Parameter Store (SSM PS)…with focus on security, centralized configuration and secrets management in a DevSecOps environments.
Breakdown:
- Overview & Use Cases
- Parameter Types & Tiers
- Security Architecture
- Access Control (IAM Policies & Conditions)
- Encryption (KMS Integration)
- Versioning, Auditing, and Change Management
- Integration with AWS Services
- Automation Patterns & Advanced Use Cases
- Best Practices & Anti-Patterns
1.
Overview & Use Cases
- AWS Systems Manager Parameter Store (SSM PS) is
a managed service for storing configuration data and secrets as
key-value pairs.
- AWS Systems Manager Parameter Store (SSM PS) provides:
- Centralized management of
environment variables, connection
strings, API keys, and other runtime config.
- Secure, auditable, versioned
storage.
- Integration with AWS services like
EC2, Lambda, ECS, and CodePipeline.
Common
Use Cases
- App configuration: Environment-specific variables (e.g. db.host, api.url, log.level).
- Secrets management: Encrypted credentials (e.g. database passwords, API tokens).
- Infrastructure automation: Parameters shared across CloudFormation, Terraform, or CI/CD pipelines.
- Cross-account configuration sharing (with KMS key policies).
2.
Parameter Types & Tiers
|
Type |
Description |
Max
Size |
Encryption |
|
String |
Plaintext data (non-sensitive). |
4 KB |
None |
|
StringList |
Comma-separated list of values. |
4 KB |
None |
|
SecureString |
Sensitive data encrypted via AWS
KMS. |
8 KB |
Yes (KMS) |
Parameter
Tiers
|
Tier |
Max
Parameters |
Max
Size |
Throughput |
Features |
|
|
Standard |
10,000 |
4 KB |
40 TPS |
Free tier |
|
|
Advanced |
100,000+ |
8 KB |
1000 TPS |
Higher throughput, policies,
expiration |
|
3.
Security Architecture
SSM Parameter Store follows shared responsibility:
- AWS secures the infrastructure (encryption, HA, access logs).
- twtech needs to define encryption keys, IAM policies,
and access boundaries.
Security
Layers
- Encryption at Rest – via KMS Customer Managed Keys (CMKs).
- Encryption in Transit – HTTPS and SigV4 signing.
- Granular IAM policies – control read/write access at parameter
or path level.
- Auditability – parameter changes logged to AWS
CloudTrail.
4.
Access Control (IAM Policies & Conditions)
twtech can scope access by:
- Parameter path (hierarchical
access)
- Parameter name
- Tag-based access
- Condition keys (e.g.
ssm:ResourceTag/Environment or ssm:ParameterName)
Example IAM policy (read-only for Dev
parameters):
# json
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "twtechReadDevParameters",
"Effect": "Allow",
"Action": [
"ssm:GetParameter",
"ssm:GetParametersByPath"
],
"Resource": "arn:aws:ssm:us-east-2:accountID:parameter/dev/*"
}
]
}
5.
Encryption (KMS Integration)
SecureString parameters are
encrypted using:
- AWS-managed key (aws/ssm), or
- Customer-managed CMK (recommended for cross-account and
auditing).
NB:
twtech can define the KMS key
explicitly:
# bash
aws ssm put-parameter --name "/prod/db/password" --value "twtechSuperSecret123" --type "SecureString" --key-id "arn:aws:kms:us-east-2:accountID:key/twtechkmskey-abcd-efgh"
KMS
Policy Example for Cross-Account Read
To allow a Lambda in another
account to decrypt a parameter:
# json
{
"Sid": "twtechAllowCrossAccountDecrypt",
"Effect": "Allow",
"Principal": {"AWS":
"arn:aws:iam::accountID:role/twtechRemoteLambdaRole"},
"Action":
["kms:Decrypt"],
"Resource": "*"
}
6.
Versioning, Auditing, and Change Management
Each parameter is versioned
automatically:
- twtech can reference specific versions (e.g. name:1).
- Old versions are retained for rollback.
- Parameter changes are logged in CloudTrail.
Example rollback:
aws ssm get-parameter --name "/app/config/db" --version 3
7.
Integration with AWS Services
|
Service |
Integration
Example |
|
EC2 / ECS / Lambda |
Fetch configs securely at runtime. |
|
CloudFormation |
Use
{{resolve:ssm-secure:/path/to/param}}. |
|
CodePipeline /
CodeBuild |
Inject environment variables
dynamically. |
|
Secrets Manager |
twtech can reference SSM parameters
inside Secrets. |
|
AWS SDKs / CLI |
Universal access across languages
and scripts. |
8. Automation
Patterns & Advanced Use Cases
1.
Hierarchical Naming Convention
Example:
/{env}/{service}/{component}/{key}
e.g.
/prod/web/api/endpoint
or
/dev/db/twtechUserPat
2.
Parameter Policies
Advanced tier allows:
- Expiration – auto-deletes expired parameters.
- Notification – CloudWatch Events before expiration.
- No-change alerting – detect stale configs.
3.
Cross-Account Replication
- Use AWS Lambda or EventBridge to replicate parameters across environments (Dev → QA → Prod).
- Encrypt each with the target account’s KMS key.
4.
Automation with SSM Documents
Automate runtime configuration
injection (e.g., at EC2 launch).
9. Best
Practices & Anti-Patterns
Best Practices
- Use SecureString for all secrets (not String).
- Use customer-managed KMS keys for
isolation & rotation.
- Tag
parameters with metadata (Environment,
Application, Owner).
- Enable CloudTrail for all Parameter
Store activities.
- Rotate
secrets periodically.
- Enforce least privilege IAM (e.g., path-level access).
Anti-Patterns
- Storing
large files (>8
KB) — use S3 + signed URLs instead.
- Hardcoding
secrets in Lambda or EC2 user data.
- Reusing the
same KMS key for all environments.
- Using
aws/ssm default key for production secrets.
Example:
End-to-End Setup
Create
a Secure Parameter
# bash
aws ssm put-parameter \
--name
"/prod/db/password" \
--type "SecureString" \
--value "twtechProdStrongP@123" \
--key-id "alias/prod-kms" \
--tags Key=Environment,Value=Prod
Retrieve
It in Lambda (Python)
# python
import boto3
import os
ssm = boto3.client('ssm')
def handler(event,
context):
param = ssm.get_parameter(
Name='/prod/db/password',
WithDecryption=True
)
db_password = param['Parameter']['Value']
print("Retrieved password for DB connection")
No comments:
Post a Comment