Source Repository Security
Branch Protection Branch protection prevents direct commits to protected branches, requiring pull requests with reviews. Protection should apply to all branches that trigger deployments. Required status checks ensure that CI/CD pipelines including security scans pass before merging. Status checks should include SAST, SCA, and policy validation. Required reviews ensure that changes are reviewed by appropriate personnel. Review requirements should scale with change risk, with production changes requiring multiple reviewers. Dismiss stale reviews when new commits are pushed, preventing approval of outdated code. Stale review dismissal ensures that reviewers see final code. Signed Commits and Tags Commit signing using GPG or SSH keys provides cryptographic proof of commit authorship. Signed commits prevent impersonation and tampering. Tag signing ensures that release tags are authentic. Tags should be signed by authorized release managers. Signature verification should be enforced in GitOps controllers, preventing deployment of unsigned commits. Verification provides supply chain security. CODEOWNERS CODEOWNERS files define required reviewers for specific paths, ensuring that security-sensitive changes are reviewed by security team. CODEOWNERS should cover infrastructure code, security policies, and secrets management. CODEOWNERS enforcement requires that designated owners approve changes to their paths. Enforcement prevents unauthorized changes to critical paths.GitOps Controller Security
Controller Hardening GitOps controllers including Flux and ArgoCD should run with minimal privileges, using dedicated service accounts with least-privilege RBAC permissions. Controllers should be deployed in dedicated namespaces with network policies restricting traffic. Network isolation prevents lateral movement from compromised controllers. Controller images should be scanned for vulnerabilities and signed. Image signing ensures controller authenticity. RBAC and Permissions Controller service accounts should have minimal RBAC permissions required for reconciliation. Overly broad permissions enable privilege escalation. Namespace-scoped controllers limit blast radius from controller compromise. Cluster-scoped controllers should be avoided where possible. Impersonation permissions should be carefully controlled, as they enable controllers to act as other users. Impersonation should be logged comprehensively. Secrets Management Secrets should be retrieved from external secret managers including HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault rather than stored in Git. External Secrets Operator or similar tools enable GitOps workflows while keeping secrets out of Git. Secret references in Git point to external secret stores. Secret encryption in Git using tools like Sealed Secrets or SOPS provides additional protection, but external secret managers are preferred. Reconciliation Logging Reconciliation logs should be shipped to centralized logging systems for audit and investigation. Logs should include what changes were applied, when, and by which controller. Log retention should meet compliance requirements, typically 90 days to one year. Logs provide audit trail for all infrastructure changes. Anomaly detection on reconciliation logs can identify unusual changes or controller compromise.Admission Control and Policy Enforcement
Signature Verification Admission controllers should verify image signatures using Cosign or similar tools before allowing pod creation. Unsigned images should be rejected. Provenance verification ensures that images were built by trusted build systems. SLSA provenance provides supply chain security. Signature verification should apply to all images including init containers and sidecars. Comprehensive verification prevents bypass. Policy as Code OPA (Open Policy Agent), Gatekeeper, or Kyverno enforce security policies at admission time. Policies should be version-controlled in Git alongside application manifests. Policies should enforce security invariants including required labels, resource limits, security contexts, and network policies. Policy violations should block deployment. Policy testing ensures that policies correctly allow compliant workloads while blocking non-compliant workloads. Tests should run in CI/CD pipelines. Deny on Violation Policy violations should deny deployment rather than warn. Warnings are ignored, while denials enforce compliance. Audit mode can be used during policy development to identify violations without blocking. Audit mode should transition to enforce mode after tuning.Multi-Tenancy
Repository and Namespace Isolation Separate repositories per team provide isolation and access control. Repository separation prevents teams from modifying each other’s configurations. Namespace-per-team provides runtime isolation with RBAC and network policies. Namespace isolation limits blast radius from compromises. Kustomize overlays enable per-team customization of shared base configurations. Overlays provide flexibility while maintaining consistency. Scoped Deploy Keys Deploy keys should be scoped to specific repositories with read-only access. Scoped keys limit impact from key compromise. Separate deploy keys per environment prevent development keys from accessing production repositories. Environment separation provides defense-in-depth. Deploy key rotation should occur regularly, with automated rotation where possible. Rotation limits exposure window from compromised keys. Cross-Tenant Audit Audit logging should cover all tenants, enabling detection of cross-tenant attacks or policy violations. Centralized audit logs provide comprehensive visibility. Tenant isolation should be validated regularly through testing. Isolation failures can enable privilege escalation.Incident Response and Rollback
Git-Based Rollback Rollback through git revert provides auditable, version-controlled rollback. Revert commits document what was rolled back and why. Automated rollback based on health checks can rapidly recover from bad deployments. Automation reduces mean time to recovery. Rollback testing should occur regularly to ensure that rollback procedures work. Untested rollback procedures fail during incidents. Deployment Freeze Deployment freeze policies prevent changes during incidents or maintenance windows. Freeze policies should be enforceable through automation. Break-glass procedures enable emergency changes during freezes, with comprehensive audit logging and automatic expiration. Break-glass should be rare and always investigated. Audit Trail Comprehensive audit trail captures all changes including who made what change when and why. Audit trail should be immutable and retained for compliance periods. Change attribution through commit authors and reviewers enables accountability. Attribution should be enforced through authentication.Conclusion
GitOps security requires securing the entire path from commit to cluster through repository protection, controller hardening, and admission control. Security engineers design GitOps workflows that enable rapid deployment while maintaining security controls. Success requires treating Git as critical infrastructure requiring comprehensive security controls. Organizations that invest in GitOps security fundamentals enable rapid, secure deployment at scale.References
- CNCF GitOps Principles
- Flux Security Documentation
- ArgoCD Security Hardening Guide
- Sigstore for Artifact Signing
- OPA/Gatekeeper Policy Examples