SOC2 & Compliance Frameworks

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.

Evidence artifacts:

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.

Evidence artifacts:

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.

Evidence artifacts:

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.

Evidence artifacts:

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.

Evidence artifacts:

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.

Evidence artifacts:

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.

Evidence artifacts:

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.

Evidence artifacts:

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.

Evidence artifacts:

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.

Evidence artifacts:

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.

About

Usage

Overview

SOC2 Trust Services Criteria Coverage

Security (Common Criteria)

CC6.1 - Logical Access Security

CC6.2 - Access Provisioning and Deprovisioning

CC6.3 - Access Removal

CC6.6 - Protection Against Threats Outside System Boundaries

CC6.7 - Transmission Encryption

CC6.8 - Malicious Software Prevention

CC8.1 - Change Management

CC8.2 - Infrastructure and Software Changes

A1.1, A1.2 - Availability

C1.1, C1.2 - Confidentiality

Control Matrix Summary

Other Compliance Frameworks

HIPAA (Healthcare)

PCI-DSS (Payment Card)

ISO 27001

Preparing for Audit

​Overview

​SOC2 Trust Services Criteria Coverage

​Security (Common Criteria)

​CC6.1 - Logical Access Security

​CC6.2 - Access Provisioning and Deprovisioning

​CC6.3 - Access Removal

​CC6.6 - Protection Against Threats Outside System Boundaries

​CC6.7 - Transmission Encryption

​CC6.8 - Malicious Software Prevention

​CC8.1 - Change Management

​CC8.2 - Infrastructure and Software Changes

​A1.1, A1.2 - Availability

​C1.1, C1.2 - Confidentiality

​Control Matrix Summary

​Other Compliance Frameworks

​HIPAA (Healthcare)

​PCI-DSS (Payment Card)

​ISO 27001

​Preparing for Audit

Overview

SOC2 Trust Services Criteria Coverage

Security (Common Criteria)

CC6.1 - Logical Access Security

CC6.2 - Access Provisioning and Deprovisioning

CC6.3 - Access Removal

CC6.6 - Protection Against Threats Outside System Boundaries

CC6.7 - Transmission Encryption

CC6.8 - Malicious Software Prevention

CC8.1 - Change Management

CC8.2 - Infrastructure and Software Changes

A1.1, A1.2 - Availability

C1.1, C1.2 - Confidentiality

Control Matrix Summary

Other Compliance Frameworks

HIPAA (Healthcare)

PCI-DSS (Payment Card)

ISO 27001

Preparing for Audit