Project Forge implements defense-in-depth security following AWS Well-Architected Framework and industry best practices for regulated industries like Finance and Defence.

• Private Subnets: All workloads run in private subnets without direct internet access
• NAT Gateways: Outbound internet access controlled through NAT
• VPC Flow Logs: All network traffic logged for auditing

# Example: EKS Node Security Group
- Ingress from control plane only
- Ingress from other nodes (pod-to-pod)
- No direct public access

# Deny all by default
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

• Principle of Least Privilege: Minimal permissions for each role
• Service-Linked Roles: Specific roles for EKS, ECS, etc.
• IAM Roles for Service Accounts (IRSA): Pod-level AWS permissions

# Example: Read-only role for developers
kind: Role
metadata:
  name: developer
rules:
  - apiGroups: [""]
    resources: ["pods", "services", "configmaps"]
    verbs: ["get", "list", "watch"]

• All internal communication uses TLS 1.2+
• Load balancer terminates external TLS
• Service mesh (optional) for mTLS

# KMS key with rotation
resource "aws_kms_key" "main" {
  enable_key_rotation = true
  deletion_window_in_days = 30
}

1. Base Images: Use minimal, distroless images
2. Vulnerability Scanning: Trivy in CI/CD pipeline
3. Image Signing: (Optional) Cosign/Notary

# Non-root user
USER 1001:1001

# Read-only filesystem
RUN chmod -R 555 /app

securityContext:
  runAsNonRoot: true
  runAsUser: 1001
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false
  capabilities:
    drop:
      - ALL

• No PII in logs
• Correlation IDs for request tracing
• Centralized log aggregation
• Log retention policies

1. Kubernetes Secrets: For non-sensitive config
2. AWS Secrets Manager: For credentials
3. External Secrets Operator: Sync to Kubernetes

• Validate all user input
• Use parameterized queries
• Sanitize output

# CI Pipeline Security Gates
- Dependency Scan (OWASP)
- Container Scan (Trivy)
- Infrastructure Scan (Checkov)
- Secret Scan (Gitleaks)
- SAST (SonarQube) - optional

• Audit Logging: All actions logged with timestamps
• Data Encryption: Encryption everywhere
• Access Controls: RBAC with audit trail
• Change Management: GitOps with approval workflows

• Network Isolation: Private subnets, no public endpoints
• Security Clearance: IAM with MFA
• Data Classification: Labels and policies
• Incident Response: Alerting and runbooks

• VPC with private subnets
• NAT Gateway for outbound traffic
• VPC Flow Logs enabled
• Security groups with least privilege
• KMS encryption enabled
• IAM roles with minimal permissions

• RBAC configured
• Pod security policies/standards
• Network policies
• Secrets encrypted
• Service accounts with IRSA

• Non-root container
• Read-only filesystem
• No hardcoded secrets
• Input validation
• Structured logging

• Container scanning
• Dependency scanning
• Secret scanning
• Infrastructure scanning
• Signed commits

• Prometheus alerts for anomalies
• CloudWatch alarms for AWS resources
• Kibana dashboards for logs

1. Detection: Automated alerting
2. Containment: Network isolation
3. Eradication: Remediation
4. Recovery: Restore from backup
5. Lessons Learned: Post-mortem

• Critical: Within 24 hours
• High: Within 7 days
• Medium: Within 30 days
• Low: Next release cycle

1. Security advisory review
2. Impact assessment
3. Test in staging
4. Deploy to production
5. Verify remediation