Security Guidelines¶

Security best practices for deploying and operating vpc-provisioner-tool.

Table of Contents¶

Credential Management
Input Validation
Network Security
VPC Resource Security
CloudFormation Security
Docker Security
Logging and Monitoring
Compliance
Incident Response
Security Checklist

Credential Management¶

AWS Credentials¶

Never hardcode credentials. Use one of these methods:

IAM Roles (Recommended for EC2/ECS/Lambda)

# No credentials needed - automatic from instance metadata
python -m vpc_provisioner.cli -con config.yaml -act create-vpc

Environment Variables

export AWS_ACCESS_KEY_ID=<access_key>
export AWS_SECRET_ACCESS_KEY=<secret_key>
export AWS_DEFAULT_REGION=us-west-2

AWS Credentials File

# ~/.aws/credentials
[default]
aws_access_key_id = <access_key>
aws_secret_access_key = <secret_key>

[production]
aws_access_key_id = <prod_access_key>
aws_secret_access_key = <prod_secret_key>

AWS SSO (Recommended for Developers)

aws sso login --profile production
export AWS_PROFILE=production

Credential Rotation¶

Rotate access keys every 90 days
Use AWS Secrets Manager for automated rotation
Monitor credential age with AWS IAM Credential Report

Input Validation¶

Configuration Files¶

Validate all configuration inputs:

# Good - follows naming conventions
company_prefix: "edge"
environment: "prod"
region: "us-west-2"

# Bad - potential security issues
company_prefix: "../../../etc"  # Path traversal
environment: "prod; rm -rf /"   # Command injection

VPC Names and CIDR Blocks¶

Enforce naming standards and valid CIDR ranges:

Lowercase alphanumeric with hyphens only
Must start and end with alphanumeric
Maximum 63 characters
No path traversal characters (../, ..\)
Valid CIDR notation (e.g., 10.0.0.0/16)

# Valid
-act create-vpc
CIDR: 10.0.0.0/16

# Invalid
CIDR: 10.0.0.0/33  # Invalid CIDR range
CIDR: 192.168.0.0/8  # Incorrect subnet mask

Network Security¶

VPC Design Principles¶

Follow AWS Well-Architected Framework:

Network Segmentation
- Use multiple subnets for different tiers (public, private, data)
- Separate development, staging, and production VPCs
- Use separate VPCs for different security zones

Subnet Strategy

# Public subnets (internet-facing resources)
public_subnet_1: 10.0.1.0/24
public_subnet_2: 10.0.2.0/24

# Private subnets (application tier)
private_subnet_1: 10.0.11.0/24
private_subnet_2: 10.0.12.0/24

# Data subnets (database tier)
data_subnet_1: 10.0.21.0/24
data_subnet_2: 10.0.22.0/24

Route Table Isolation
- Separate route tables for public and private subnets
- Public subnets route to Internet Gateway
- Private subnets route to NAT Gateway
- Data subnets have no internet access

Security Groups¶

Implement least privilege access:

# Good - specific rules
aws ec2 authorize-security-group-ingress \
  --group-id sg-12345678 \
  --protocol tcp \
  --port 443 \
  --source-group sg-87654321

# Bad - overly permissive
aws ec2 authorize-security-group-ingress \
  --group-id sg-12345678 \
  --protocol all \
  --cidr 0.0.0.0/0

Best practices:

Never use 0.0.0.0/0 for inbound rules (except specific use cases)
Use security group references instead of CIDR blocks
Document all security group rules
Regular audit of security group rules
Remove unused security groups

Network ACLs¶

Use NACLs as additional defense layer:

# Deny known malicious IPs
aws ec2 create-network-acl-entry \
  --network-acl-id acl-12345678 \
  --rule-number 50 \
  --protocol -1 \
  --rule-action deny \
  --cidr-block 203.0.113.0/24

Best practices:

Use NACLs for subnet-level protection
Keep NACL rules simple and well-documented
Lower rule numbers take precedence
Always have explicit deny rules

VPC Flow Logs¶

Enable VPC Flow Logs for monitoring:

aws ec2 create-flow-logs \
  --resource-type VPC \
  --resource-ids vpc-12345678 \
  --traffic-type ALL \
  --log-destination-type cloud-watch-logs \
  --log-group-name /aws/vpc/flowlogs

Benefits:

Monitor network traffic patterns
Detect anomalous behavior
Troubleshoot connectivity issues
Meet compliance requirements

VPC Resource Security¶

Internet Gateway¶

Attach only to VPCs requiring internet access:

Only public subnets should route to IGW
Monitor IGW attachment/detachment events
Use NAT Gateway for private subnet internet access

NAT Gateway¶

Secure outbound internet access:

Deploy NAT Gateway in public subnet
Use Elastic IP for consistent outbound IP
Monitor NAT Gateway metrics (bytes, packets, errors)
Consider NAT Gateway per AZ for high availability

VPC Endpoints¶

Use VPC endpoints for AWS service access:

# Configuration with VPC endpoints
vpc_endpoints:
  - service: s3
    type: gateway
  - service: ec2
    type: interface

Benefits:

Traffic never leaves AWS network
No internet gateway required
Reduced data transfer costs
Enhanced security posture

VPC Peering¶

Secure VPC-to-VPC communication:

Use VPC peering for trusted VPC connections
Avoid transitive peering
Update route tables carefully
Monitor peering connection status

CloudFormation Security¶

Stack Policies¶

Protect production stacks:

{
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "Update:Delete",
      "Resource": "*"
    }
  ]
}

Drift Detection¶

Monitor for configuration drift:

aws cloudformation detect-stack-drift \
  --stack-name edge-prod-b001-us-west-2-vpc-stack

Docker Security¶

Image Security¶

Use minimal base images:

# Good - minimal attack surface
FROM python:3.11-slim

# Bad - large attack surface
FROM python:3.11

Secrets Management¶

Never bake credentials into images:

# Bad - credentials in image
ENV AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE

# Good - mount credentials at runtime
# Use IAM roles or mount ~/.aws/credentials

Container Scanning¶

Scan images for vulnerabilities:

# Using Docker Scout
docker scout cves vpc-provisioner:latest

# Using Trivy
trivy image vpc-provisioner:latest

Logging and Monitoring¶

CloudTrail¶

Enable CloudTrail for audit logs:

Log all VPC API calls
Log all EC2 API calls
Log all CloudFormation operations
Store logs in separate security account
Enable log file validation

CloudWatch Alarms¶

Monitor for suspicious activity:

# Alert on VPC deletion
aws cloudwatch put-metric-alarm \
  --alarm-name vpc-deletion \
  --metric-name DeleteVpc \
  --namespace AWS/EC2 \
  --statistic Sum \
  --period 300 \
  --threshold 1 \
  --comparison-operator GreaterThanThreshold

Application Logs¶

Secure log storage:

Store logs in dedicated S3 bucket
Enable log encryption
Set lifecycle policies for retention
Restrict access to security team

Compliance¶

Data Residency¶

Enforce regional restrictions:

{
  "Condition": {
    "StringEquals": {
      "aws:RequestedRegion": ["us-west-1", "us-west-2"]
    }
  }
}

Tagging Strategy¶

Tag all resources for governance:

Tags:
  - Key: Environment
    Value: prod
  - Key: Owner
    Value: network-team
  - Key: CostCenter
    Value: engineering
  - Key: Compliance
    Value: sox
  - Key: DataClassification
    Value: confidential

Incident Response¶

Compromised Credentials¶

If credentials are compromised:

Immediately disable credentials:

aws iam update-access-key \
  --access-key-id AKIAIOSFODNN7EXAMPLE \
  --status Inactive

Review CloudTrail logs:

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIAIOSFODNN7EXAMPLE

Rotate all credentials
Review IAM policies
Check for unauthorized resources

Unauthorized Network Access¶

If unauthorized access detected:

Review security group rules
Check NACL configurations
Analyze VPC Flow Logs
Review CloudTrail for API calls
Update security groups and NACLs
Consider VPC isolation

VPC Resource Tampering¶

If VPC resources are modified:

Run CloudFormation drift detection
Review CloudTrail for modification events
Restore from CloudFormation stack
Update stack policies to prevent changes
Enable MFA for destructive operations

Security Contacts¶

Security Team: security@company.com
AWS Support: AWS Enterprise Support
Incident Response: incident-response@company.com