PluginBench
Skill
Pass
Audit score 90

securing-s3-buckets

aws/agent-toolkit-for-aws

Create and secure S3 buckets following AWS best practices for access control, encryption, monitoring, and remediation.

What is securing-s3-buckets?

Implements layered S3 security controls across five workflows: securing new buckets, auditing existing configurations, remediating findings, configuring encryption, and enabling monitoring. Use when you need to secure a new bucket, audit an existing bucket, fix a security finding, configure encryption, or enable logging and monitoring. Do NOT use for general S3 data operations or discovering existing data assets.

  • Secure new S3 buckets with versioning, encryption, logging, HTTPS-only enforcement, and ABAC
  • Audit existing bucket configurations against AWS Well-Architected security best practices
  • Remediate security findings and misconfigurations with guided fix commands
  • Configure encryption options including SSE-S3, SSE-KMS with customer-managed keys, and SSE-C blocking
  • Enable monitoring via CloudTrail, GuardDuty, AWS Config, and S3 server access logging

How to install securing-s3-buckets

npx skills add https://github.com/aws/agent-toolkit-for-aws --skill securing-s3-buckets
Prerequisites
  • AWS CLI installed and configured with valid credentials
  • IAM permissions appropriate to the workflow (see references/iam-permissions.md)
  • Confirmation of AWS credentials via aws sts get-caller-identity
Claude Code
Cursor
Windsurf
Cline

How to use securing-s3-buckets

  1. 1.Verify dependencies and confirm AWS credentials with aws sts get-caller-identity
  2. 2.Classify your request: securing a new bucket, auditing existing, remediating a finding, configuring encryption, or enabling monitoring
  3. 3.Provide required parameters upfront: bucket name, region, and any specific security requirements
  4. 4.Review and confirm all write commands before execution, especially bucket policy changes
  5. 5.Run audit checks after remediation to confirm the fix resolved the issue

Use cases

Good for
  • Create a new S3 bucket with all security controls enabled from the start
  • Review an existing bucket's security posture and identify gaps against best practices
  • Fix a specific security finding such as missing encryption or unencrypted transport
  • Switch from SSE-S3 to customer-managed KMS encryption for sensitive data
  • Enable CloudTrail and GuardDuty monitoring for compliance and threat detection
Who it's for
  • AWS security engineers and architects
  • DevOps and platform teams managing S3 infrastructure
  • Compliance and audit teams reviewing bucket configurations
  • Developers provisioning secure S3 storage for applications

securing-s3-buckets FAQ

What happens if I run put-bucket-policy on a bucket with an existing policy?

The command replaces the entire policy. The skill MUST back up the existing policy first using get-bucket-policy, then merge new statements into the existing Statement array before applying.

Do I need to use customer-managed KMS keys or can I use the AWS managed aws/s3 key?

You MUST use a customer-managed key when configuring SSE-KMS. The AWS managed aws/s3 key is not permitted. Specify keys by full ARN, not alias.

What should I do if I get an AccessDenied error during an audit?

Check your IAM policy, bucket policy, Block Public Access settings, VPC endpoint policy, and any SCPs/RCPs. Use aws iam simulate-principal-policy to diagnose the exact permission gap.

Can I use this skill for general S3 data operations like uploading or listing objects?

No. This skill is for security configuration only. Do NOT use it for general S3 data operations, S3 Tables setup, or discovering existing data assets.

What is the --bucket-namespace account-regional flag and is it required?

Yes, it is REQUIRED when creating a new bucket. It ensures the bucket is created in the account-regional namespace, which is a best practice for S3 bucket naming and isolation.

Full instructions (SKILL.md)

Source of truth, from aws/agent-toolkit-for-aws.


name: securing-s3-buckets description: > Create and secure S3 buckets following AWS best practices for access control, encryption, monitoring, and remediation of misconfigurations. Use when the user wants to secure a new bucket, audit an existing bucket, fix a security finding, configure encryption, or enable logging and monitoring. Do NOT use for general S3 data operations, S3 Tables setup, or discovering existing data assets. version: 1

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 for IAM permissions by workflow.

1. Classify the Request

User intentWorkflow
Secure a new bucketA: Secure New Bucket
Audit / review existing bucketB: Audit Existing Bucket
Fix a specific findingC: Remediate Issue
Configure encryptionD: Configure Encryption
Enable logging / monitoringE: 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 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:SecureTransport":"false"}}}]}'
    
  • You MUST ask the user which logging option they want before step 4

  • You MUST follow the put-bucket-policy safety rules for steps 4 and 5

  • You SHOULD confirm each step succeeded before proceeding

3. Workflow B — Audit Existing Bucket

See references/audit-checklist.md for the full checklist.

Constraints:

  • You MUST run all read-only audit commands before reporting findings
  • You MUST NOT execute any write or modify commands during an audit
  • You MUST report each control as PASS / FAIL / NOT CONFIGURED with severity
  • For logging: report PASS if either S3 server access logging OR CloudTrail data events are enabled; NOT CONFIGURED only if neither

4. Workflow C — Remediate Issue

See references/remediation.md for fix commands by issue type.

Constraints:

  • You MUST identify the issue type before applying any fix
  • You MUST follow the put-bucket-policy safety rules when modifying policies
  • You MUST re-run the relevant audit check after applying the fix to confirm resolution

5. Workflow D — Configure Encryption

See references/encryption.md for encryption options and commands.

Constraints:

  • You MUST default to SSE-S3 with S3 Bucket Keys and SSE-C blocked unless the user explicitly requests KMS
  • When using SSE-KMS, you MUST use a customer managed key — NEVER the AWS managed aws/s3 key
  • You MUST specify customer-managed KMS keys by full ARN, not alias
  • You MUST include BucketKeyEnabled: true and BlockedEncryptionTypes: [SSE-C] in all configurations
  • Note: The S3 API accepts aws/s3 and aliases without error — agent-enforced constraints. Verify with get-bucket-encryption after applying.

6. Workflow E — Enable Monitoring

See references/workflows.md for full CLI steps.

Constraints:

  • You MUST check whether a GuardDuty detector already exists before creating one
  • You MUST use the trail's home region (not the bucket's region) for CloudTrail commands
  • You SHOULD enable all four core recommended AWS Config rules

Troubleshooting

ObjectLockConfigurationNotFoundError — Object Lock is not enabled. Treat as NOT CONFIGURED, not a failure.

AccessDenied on audit commands — Check IAM policy, bucket policy, Block Public Access, VPC endpoint policy, and SCPs/RCPs. Use aws iam simulate-principal-policy to diagnose.

put-bucket-policy silently removes existing statements — See put-bucket-policy safety rules.

GuardDuty BadRequestException: detector already exists — Run aws guardduty list-detectors first; only call create-detector if empty.

CloudTrail changes not taking effect — Verify you are using --region <trail-home-region>, not the bucket's region. Find it with aws cloudtrail describe-trails --query 'trailList[*].[Name,HomeRegion]'.

Additional Resources