Overview
Kube Starter Kit is designed with security and auditability as core principles. While the kit itself doesn’t make you SOC2 compliant (that requires organizational policies, procedures, and a formal audit), it provides the technical foundation that addresses many SOC2 Trust Services Criteria.
This page maps Kube Starter Kit features to specific SOC2 controls and explains how they support your compliance posture.
SOC2 Trust Services Criteria Coverage
SOC2 audits evaluate controls across five Trust Services Criteria. Kube Starter Kit primarily addresses Security (Common Criteria) and Availability, with supporting capabilities for Processing Integrity and Confidentiality.
Security (Common Criteria)
The Security category forms the foundation of SOC2 and is required for all audits.
CC6.1 - Logical Access Security
The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events.
| Control Requirement | Kube Starter Kit Feature | Implementation |
|---|
| Role-based access control | User Management | Single users.yaml defines AWS SSO users, groups, and permission sets. GitHub teams mirror AWS groups for consistent RBAC. |
| Centralized identity management | User Management | AWS IAM Identity Center provides centralized authentication. No long-lived credentials; users authenticate via SSO portal. |
| Least privilege enforcement | User Management | Pre-configured permission sets (Admin, PowerUser, ReadOnly) with AWS-managed policies. Easy to add custom permission sets for more granular access. |
| Network segmentation | AWS Architecture | EKS nodes run in private subnets with no public IPs. Workloads are isolated from direct internet access. |
| Multi-account isolation | AWS Architecture | Staging and production in separate AWS accounts. Hard boundary prevents cross-environment access or accidental impact. |
- Git history of
users.yaml changes showing access reviews
- AWS IAM Identity Center user/group listings
- Terraform state showing VPC and subnet configurations
CC6.2 - Access Provisioning and Deprovisioning
Prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users.
| Control Requirement | Kube Starter Kit Feature | Implementation |
|---|
| Documented access requests | User Management | All access changes are pull requests. PR description documents who, what, and why. |
| Approval workflow | User Management | Branch protection requires PR approval before merge. Access changes get code review. |
| Automated provisioning | Terraform + Terramate | Merging approved PRs triggers Terraform apply. No manual AWS console access needed. |
| Timely deprovisioning | User Management | Remove user from users.yaml, open PR, merge. Access revoked across GitHub and AWS simultaneously. |
- Pull request history showing access change approvals
- Git blame on
users.yaml showing who approved each change
- Terraform plan outputs showing exact access modifications
CC6.3 - Access Removal
The entity removes access to protected information assets when appropriate.
| Control Requirement | Kube Starter Kit Feature | Implementation |
|---|
| Single source of truth | User Management | One file controls all access. Removing a user entry revokes GitHub org membership, team access, and AWS SSO access. |
| Audit trail | GitOps | Git history provides immutable record of when access was removed and by whom. |
| No orphaned access | Terraform + Terramate | Terraform manages state declaratively. Users not in users.yaml are removed on apply. |
- Git commits showing user removal
- Terraform destroy plans for removed users
- AWS CloudTrail logs showing SSO user deletion
CC6.6 - Protection Against Threats Outside System Boundaries
The entity implements logical access security measures to protect against threats from sources outside its system boundaries.
| Control Requirement | Kube Starter Kit Feature | Implementation |
|---|
| TLS encryption | Kubernetes Baseline | cert-manager automatically provisions and renews Let’s Encrypt certificates for all ingress endpoints. |
| No default credentials | Kubernetes Baseline | External Secrets pulls credentials from AWS Secrets Manager. No secrets in Git, no default passwords. |
| Network perimeter controls | AWS Architecture | NLB with security groups controls inbound traffic. Private subnets prevent direct access to nodes. |
| Container vulnerability scanning | Image Scanning | Daily CVE scans against production images. SBOM generation for supply chain visibility. |
- cert-manager Certificate resources showing valid TLS
- CVE scan reports from GitHub Actions
- VPC security group configurations
CC6.7 - Transmission Encryption
The entity restricts the transmission, movement, and removal of information to authorized internal and external users and processes.
| Control Requirement | Kube Starter Kit Feature | Implementation |
|---|
| Encryption in transit | Kubernetes Baseline | All external traffic terminates TLS at traefik. Internal cluster traffic uses Kubernetes network policies. |
| Automated certificate management | Kubernetes Baseline | cert-manager handles certificate lifecycle. No manual certificate handling or risk of expiration. |
- Ingress resources with TLS configuration
- Certificate resources showing renewal history
CC6.8 - Malicious Software Prevention
The entity implements controls to prevent or detect and act on the introduction of unauthorized or malicious software.
| Control Requirement | Kube Starter Kit Feature | Implementation |
|---|
| Container image scanning | Image Scanning | Grype scans all container images for known CVEs. Reports generated with severity breakdowns. |
| SBOM generation | Image Scanning | Syft generates Software Bill of Materials for each image. Enables tracking of vulnerable dependencies. |
| Immutable deployments | CI/CD Pipeline | Container images are tagged with version and commit hash. Tags are never overwritten. |
- CVE scan reports and SBOM artifacts
- ECR image tags showing immutable versioning
- GitHub Actions workflow runs
CC8.1 - Change Management
The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures.
| Control Requirement | Kube Starter Kit Feature | Implementation |
|---|
| Change authorization | GitOps | All changes require pull request approval. Branch protection enforces review requirements. |
| Change documentation | GitOps | Git commits document what changed. PR descriptions explain why. Rendered manifests show exact Kubernetes changes. |
| Separation of environments | AWS Architecture | Changes deploy to staging first. Production deployment requires separate approval/promotion. |
| Automated testing | CI/CD Pipeline | CI runs on every PR. Manifest validation ensures rendered output matches committed files. |
| Rollback capability | GitOps | Reverting a Git commit triggers ArgoCD rollback. Previous state is always recoverable. |
- Pull request history with approvals
- Git diff showing exact changes per deployment
- ArgoCD sync history showing deployments
CC8.2 - Infrastructure and Software Changes
The entity authorizes, documents, and implements changes to infrastructure and software.
| Control Requirement | Kube Starter Kit Feature | Implementation |
|---|
| Infrastructure as Code | Terraform + Terramate | All AWS infrastructure defined in Terraform. Changes visible in PR diffs. |
| Change visibility | Terramate | terraform plan output posted to PRs. Reviewers see exactly what will change before approval. |
| Drift detection | Terramate | Scheduled workflows detect infrastructure drift. Alerts when actual state differs from code. |
| Kubernetes changes | GitOps | Rendered manifests committed to Git. ArgoCD shows diff between desired and actual state. |
- Terraform plan outputs in PRs
- Drift detection workflow results
- ArgoCD application sync status
A1.1, A1.2 - Availability
The entity maintains, monitors, and evaluates current processing capacity and use of system components to support availability.
| Control Requirement | Kube Starter Kit Feature | Implementation |
|---|
| Capacity management | Kubernetes Baseline | Karpenter auto-provisions nodes based on workload demand. Removes underutilized capacity automatically. |
| High availability | AWS Architecture | EKS spans 3 availability zones. Node failures don’t affect application availability. |
| Observability | Kubernetes Baseline | SigNoz provides metrics, logs, and traces. Enables monitoring of system health and performance. |
| Database resilience | Kubernetes Baseline | CloudNativePG provides automated failover for PostgreSQL. Backups to S3 enable point-in-time recovery. |
- Karpenter provisioner logs
- SigNoz dashboards and alerts
- CloudNativePG backup records
C1.1, C1.2 - Confidentiality
The entity identifies and maintains confidential information to meet the entity’s objectives related to confidentiality.
| Control Requirement | Kube Starter Kit Feature | Implementation |
|---|
| Secrets management | Kubernetes Baseline | External Secrets syncs credentials from AWS Secrets Manager. Secrets never stored in Git. |
| Encryption at rest | AWS Architecture | EBS volumes, S3 buckets, and Secrets Manager all encrypted with KMS by default. |
| Access to secrets | Kubernetes Baseline | Pod Identity provides scoped AWS credentials. Pods only access secrets they’re authorized for. |
- ExternalSecret resources (not containing actual secret values)
- AWS Secrets Manager access logs
- Pod Identity association configurations
Control Matrix Summary
| SOC2 Control | Primary Feature | Evidence Location |
|---|
| CC6.1 - Logical Access | User Management | users.yaml + Git history |
| CC6.2 - Access Provisioning | User Management | Pull requests |
| CC6.3 - Access Removal | User Management | Git commits + Terraform state |
| CC6.6 - External Threats | Image Scanning, TLS | CVE reports, Certificates |
| CC6.7 - Transmission Encryption | cert-manager | Ingress TLS configs |
| CC6.8 - Malicious Software | Image Scanning | SBOM + CVE reports |
| CC8.1 - Change Management | GitOps | Git history + ArgoCD |
| CC8.2 - Infrastructure Changes | Terraform/Terramate | Plan outputs + drift detection |
| A1.1/A1.2 - Availability | Karpenter, Multi-AZ | Provisioner logs, SigNoz |
| C1.1/C1.2 - Confidentiality | External Secrets | Secrets Manager audit logs |
Other Compliance Frameworks
The same technical controls that support SOC2 also map to other compliance frameworks:
HIPAA (Healthcare)
| HIPAA Requirement | Kube Starter Kit Feature |
|---|
| Access Controls (§164.312(a)(1)) | User Management with RBAC |
| Audit Controls (§164.312(b)) | GitOps audit trail + CloudTrail |
| Transmission Security (§164.312(e)(1)) | TLS via cert-manager |
| Integrity Controls (§164.312(c)(1)) | Immutable container images |
PCI-DSS (Payment Card)
| PCI-DSS Requirement | Kube Starter Kit Feature |
|---|
| Req 1: Network Segmentation | Private subnets, security groups |
| Req 2: Secure Configurations | Infrastructure as Code |
| Req 6: Secure Development | CI/CD with vulnerability scanning |
| Req 7: Restrict Access | RBAC via User Management |
| Req 8: Identify Users | AWS IAM Identity Center |
| Req 10: Track Access | Git audit trail + CloudTrail |
ISO 27001
| ISO 27001 Control | Kube Starter Kit Feature |
|---|
| A.9 Access Control | User Management |
| A.12 Operations Security | GitOps, CI/CD |
| A.14 System Development | IaC, rendered manifests |
| A.16 Incident Management | Observability (SigNoz) |
Preparing for Audit
While Kube Starter Kit provides the technical controls, a SOC2 audit also requires:
-
Policies and Procedures: Written documentation of your access control policy, change management process, incident response plan, etc.
-
Evidence Collection: Regular exports of:
- Git history for access changes
- Terraform plan outputs
- CVE scan reports
- ArgoCD sync history
-
Access Reviews: Periodic review of
users.yaml to verify access is still appropriate.
-
Risk Assessments: Documentation of how you triage and remediate CVE findings.
-
Training Records: Evidence that team members understand security procedures.
Start early: Begin collecting evidence before your audit period. The Git-based workflow automatically creates an audit trail, but you’ll want to establish the rhythm of periodic reviews and documentation.
