Creating Secrets Using Best Practices
Create and govern AWS Secrets Manager entries with KMS encryption, rotation, least-privilege IAM, and audit-friendly lifecycle controls.
Overview
Creating Secrets Using Best Practices is an agent skill for the Ship phase that provisions AWS Secrets Manager secrets with KMS encryption, rotation, least-privilege access, and lifecycle controls.
Install
npx skills add https://github.com/aws/agent-toolkit-for-aws --skill creating-secrets-using-best-practicesWhat is this skill?
- End-to-end SOP for Secrets Manager with required upfront parameter collection
- KMS-backed encryption with optional dedicated key creation
- Automatic rotation with configurable interval and optional Lambda rotation ARN
- Least-privilege IAM for allowed principals plus CloudTrail auditing guidance
- Tagging, recovery window, and deletion lifecycle defaults (e.g. 30-day recovery)
- Default rotation interval parameter: 30 days
- Default recovery window before permanent deletion: 30 days
- Secret types enumerated: database, api-key, oauth, custom
Adoption & trust: 1.1k installs on skills.sh; 819 GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need production credentials in AWS without weak defaults, missing rotation, or over-broad IAM that becomes a breach waiting to happen.
Who is it for?
Solo builders shipping on AWS who want a checklist-driven first secret or to standardize how agents create secrets across services.
Skip if: Teams not on AWS, local-only `.env` prototypes with no cloud deploy, or cases where secrets already exist and you only need read/rotate without recreation.
When should I use this skill?
You need to create or standardize a secret in AWS Secrets Manager with encryption, rotation, and access policies.
What do I get? / Deliverables
You get a documented, policy-aligned secret in Secrets Manager with encryption, optional rotation, scoped access, and tagging—ready to wire into apps or CI.
- Created Secrets Manager secret
- KMS encryption configuration
- Rotation and IAM access plan
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Secret provisioning is the canonical security gate before production deploys and ongoing credential hygiene. Maps to ship/security because the SOP centers on hardened secret creation, access policy, and rotation—not generic infra provisioning.
Where it fits
Provision a production database password with rotation before enabling the backend deploy pipeline.
Rotate an OAuth client secret after a vendor breach without leaving orphaned IAM policies.
Stand up API key storage the agent can reference when wiring third-party SDKs.
How it compares
Use instead of one-off console secret creation or dumping keys into parameter stores without rotation and access review.
Common Questions / FAQ
Who is creating-secrets-using-best-practices for?
Indie and solo builders using AWS who delegate secret setup to coding agents and want security baselines baked into the workflow.
When should I use creating-secrets-using-best-practices?
During Ship when onboarding databases or API keys, and during Operate when replacing credentials or tightening IAM after an incident or audit.
Is creating-secrets-using-best-practices safe to install?
Review the Security Audits panel on this page and restrict agent permissions; the skill guides secret creation that touches KMS, IAM, and live secret values.
SKILL.md
READMESKILL.md - Creating Secrets Using Best Practices
# Create Secrets Using Best Practices ## Overview This SOP provides a comprehensive approach to creating and managing secrets in AWS Secrets Manager following security best practices. It covers creating secrets with proper encryption using KMS, implementing automatic rotation, configuring least-privilege IAM policies, enabling CloudTrail auditing, and setting up lifecycle management with proper tagging and deletion policies. ## Parameters - **secret_name** (required): The name of the secret to create - **secret_description** (required): Description of what the secret contains - **secret_type** (required): Type of secret (database, api-key, oauth, custom) - **secret_value** (required): The secret value or JSON structure - **aws_region** (required): The AWS region where the secret will be created - **kms_key_id** (optional): KMS key ID for encryption (will create if not provided) - **enable_rotation** (optional, default: true): Whether to enable automatic rotation - **rotation_interval** (optional, default: 30): Rotation interval in days - **lambda_function_arn** (optional): ARN of Lambda function for custom rotation - **allowed_principals** (optional): List of IAM principals that should have access - **tags** (optional): Key-value pairs for resource tagging - **recovery_window** (optional, default: 30): Recovery window in days before permanent deletion **Constraints for parameter acquisition:** - You MUST ask for all required parameters upfront in a single prompt rather than one at a time - You MUST support multiple input methods including: - Direct input: Text provided directly in the conversation - File path: Path to a local file containing secret configuration - URL: Link to configuration resources - You MUST validate secret_type is one of: database, api-key, oauth, custom - You MUST confirm successful acquisition of all parameters before proceeding - You MUST NOT log or display the actual secret value in any output ## Steps ### 1. Verify Dependencies Check for required tools and warn the user if any are missing. **Constraints:** - You MUST verify the following tools are available in your context: - call_aws - You MUST ONLY check for tool existence and MUST NOT attempt to run the tools because running tools during verification could cause unintended side effects - You MUST inform the user about any missing tools with a clear message - You MUST ask if the user wants to proceed anyway despite missing tools - You MUST respect the user's decision to proceed or abort - You MUST explain the reason for every tool call before executing it throughout the entire SOP - You MUST verify AWS CLI is properly configured with this command: ``` aws sts get-caller-identity ``` ### 2. Create or Verify KMS Key Set up KMS key for secret encryption if not provided. **Constraints:** - If kms_key_id is provided, You MUST verify the key exists and is accessible - If kms_key_id is not provided, You MUST create a new KMS key specifically for secrets - You MUST configure the KMS key policy to grant the calling principal `kms:GenerateDataKey`, `kms:Decrypt`, and `kms:DescribeKey` permissions, scoped with the condition key `kms:ViaService` set to `secretsmanager.{aws_region}.amazonaws.com` so the key can only be used through Secrets Manager - If allowed_principals is provided, You MUST add those principals to the key policy with `kms:Decrypt` and `kms:DescribeKey` permissions (read-only access to decrypt secrets) - You MUST ensure the key policy retains the root account as key administrator to prevent lockout - You MUST enable key rotation for the KMS key - You MUST tag the KMS key with appropriate metadata ### 3. Create the Secret Create the secret in AWS Secrets Manager with proper configuration. **Constraints:** - You MUST create the secret using the specified KMS key for encryption - You MUST set the description and tags as provided - You MUST configure the secret based on the secret_type: - For database: Structure