Securing S3 Buckets
Apply layered S3 access, encryption, audit, and monitoring controls on AWS when you are hardening buckets before or after go-live.
Overview
Securing S3 Buckets is an agent skill most often used in Ship (also Operate) that implements layered AWS S3 security across secure, audit, remediate, encryption, and monitoring workflows.
Install
npx skills add https://github.com/aws/agent-toolkit-for-aws --skill securing-s3-bucketsWhat is this skill?
- Five workflows: secure new bucket, audit existing, remediate findings, configure encryption, enable logging and monitori
- Classifies user intent into workflow A–D before running commands
- AWS MCP server path with sandboxed execution, audit logging, and CLI fallback
- Dependency and credential checks including aws sts get-caller-identity
- IAM permission reference by workflow in bundled references
- Five security workflows: secure new, audit, remediate, encryption, and monitoring
Adoption & trust: 1.1k installs on skills.sh; 819 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need production S3 buckets that pass audits and stop public or unencrypted exposure, but agent-generated AWS commands easily skip logging, encryption, or least-privilege steps.
Who is it for?
Indie builders shipping on AWS who must secure or fix S3 after a security review, new environment setup, or a concrete misconfiguration finding.
Skip if: General S3 upload or lifecycle chores, S3 Tables provisioning, or inventory-only discovery of existing data assets—the skill explicitly excludes those intents.
When should I use this skill?
User wants to secure a new bucket, audit an existing bucket, fix a security finding, configure encryption, or enable logging and monitoring on S3.
What do I get? / Deliverables
You end with bucket configurations aligned to AWS security best practices, documented remediations for findings, and monitoring hooks appropriate to the classified workflow.
- Classified workflow plan
- Applied or documented S3 security controls
- Remediation steps for identified findings
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Ship because misconfigured buckets are launch blockers and compliance risks you fix before trusting production traffic. Security subphase matches audit, remediation, encryption, and Well-Architected control workflows rather than casual data upload tasks.
Where it fits
Harden a new production bucket with encryption and public-access blocks before deploying the app backend.
Run the audit workflow after a pre-launch checklist flags ambiguous bucket policies.
Enable logging and monitoring on an existing bucket when investigating access anomalies.
Remediate a specific Config or scanner finding on a live bucket without rewriting the whole stack.
How it compares
Use this procedural security workflow instead of asking the agent for ad-hoc aws s3api one-liners without audit classification.
Common Questions / FAQ
Who is securing-s3-buckets for?
Solo and indie builders (and small teams) running workloads on AWS who want an agent-guided, Well-Architected path to S3 access control, encryption, and observability—not casual object storage tasks.
When should I use securing-s3-buckets?
Use it when securing a new bucket, auditing an existing bucket, fixing a specific security finding, configuring encryption, or enabling logging and monitoring; it also supports ongoing Operate checks when bucket drift appears in production.
Is securing-s3-buckets safe to install?
It can invoke AWS APIs and shell commands against your account, so review the Security Audits panel on this page and confirm IAM scope in references/iam-permissions.md before granting agent access.
SKILL.md
READMESKILL.md - Securing S3 Buckets
## Overview Implements layered S3 security controls across five workflows: securing new buckets, auditing existing configurations, remediating findings, configuring encryption, and enabling monitoring. Follows AWS Well-Architected security best practices. Execute commands using the AWS MCP server when connected (sandboxed execution, audit logging, observability). Fall back to AWS CLI or shell otherwise. ## Common Tasks ### 0. Verify Dependencies Check for required tools before starting. **Constraints:** - You MUST inform the user if required tools are missing - You SHOULD confirm credentials with `aws sts get-caller-identity` See [references/iam-permissions.md](references/iam-permissions.md) for IAM permissions by workflow. ### 1. Classify the Request | User intent | Workflow | |---|---| | Secure a new bucket | A: Secure New Bucket | | Audit / review existing bucket | B: Audit Existing Bucket | | Fix a specific finding | C: Remediate Issue | | Configure encryption | D: Configure Encryption | | Enable logging / monitoring | E: Enable Monitoring | **Constraints:** - You MUST ask for all required parameters upfront - You MUST confirm bucket name and region before any write operation - You MAY infer region from user context if clearly stated - You SHOULD run `aws iam simulate-principal-policy` to validate permissions before write operations - You SHOULD display write commands and wait for confirmation before executing ### put-bucket-policy Safety Rules These rules apply to ALL workflows that call `put-bucket-policy`: - You MUST attempt to retrieve the existing policy first (`aws s3api get-bucket-policy`) — `put-bucket-policy` replaces the entire policy - If a policy exists, you MUST back it up before modifying: `aws s3api get-bucket-policy --bucket <name> --output text > backup-policy-$(date +%s).json` - If `NoSuchBucketPolicy` is returned, proceed with a new policy — no backup is needed - You MUST merge new statements into the existing policy's Statement array (if one exists) - You MUST validate merged JSON syntax before applying (e.g. `echo '<policy>' | python3 -m json.tool`) - You SHOULD display the full `put-bucket-policy` command and wait for confirmation ### 2. Workflow A — Secure New Bucket See [references/workflows.md](references/workflows.md) for full CLI steps. **Required steps (execute in order, do not skip):** 1. Create bucket with `--bucket-namespace account-regional` 2. Enable versioning 3. Enable encryption (SSE-S3 + Bucket Keys + block SSE-C) 4. Enable logging (ask user which option — conditional) 5. Enforce HTTPS-only via `DenyInsecureTransport` bucket policy 6. Enable ABAC **Constraints:** - You MUST pass `--bucket-namespace account-regional` on `create-bucket` call — this is REQUIRED, not optional. Example: ``` aws s3api create-bucket --bucket <name> --bucket-namespace account-regional --region <region> ``` - You MUST NOT change Block Public Access — S3 enables it by default on new buckets - You MUST NOT change ACL ownership controls — S3 disables ACLs (`BucketOwnerEnforced`) by default - You MUST apply a bucket policy with a `DenyInsecureTransport` statement that denies `s3:*` when `aws:SecureTransport` is `false` — this is REQUIRED, not optional. Example: ``` aws s3api put-bucket-policy --bucket <name> --policy '{"Version":"2012-10-17","Statement":[{"Sid":"DenyInsecureTransport","Effect":"Deny","Principal":"*","Action":"s3:*","Resource":["arn:aws:s3:::<name>/*","arn:aws:s3:::<name>"],"Condition":{"Bool":{"aws:SecureTranspor