This document outlines a proposed approach to continuous security and compliance called GitSec. It proposes centralized policy management by storing policies in versioned Git repositories. A policy manager and various adapters would connect these policies to enforcement points across Kubernetes, Istio, and other systems. The Open Policy Agent (OPA) is identified as a way to develop policies using the Rego language and deploy them as sidecars or standalone apps. The approach aims to provide uniform real-time policies, bridge between business and technical policies, and create confidence and auditability through a centralized approach to policy management. The ideas are sound but more detail and implementation work is needed, especially in integrating with component-specific policy definitions and supporting Open Policies.

1. Andreas Zitzelsberger, QAware
@andreasz82
github.com/az82
Engineering Continuous
Security and Compliance

2. The Problem

3. Source: NASA

4. Source: Monty Python’s Flying Circus

5. Developers
Managers
Auditors
Regulators
Security
Officers
Architects
Customers
Source: NASA

6. Developers
Managers
Auditors
Regulators
Security
Officers
Architects
Customers

7. k8s Admission Controller
k8s Network Policy
Clair / OWASP results
Copper.sh rules
k8s Pod Security Policy
Istio Traffic Mgmt Policy
Istio Auth Policy
KubeCI pipeline anatomy
SonarQube rules
Hosts of
Enforcement Points
A Legion of
Compliance Sources
ISO 27001
GDPR
BAFIN
HIPAA
CIS
NIST
BSI
...
...
?
?

8. What Do We Need?

9. We need Continuous Security
together with Continuous Compliance,
automated,
making things more secure,
making professional’s lives easier
and not getting in the way of productive development.

10. Source: Getty Images

11. The Goals

12. Centralized policy management creates confidence and auditability
Uniform real-time policies prevent costly mistakes
Bridging business and technical policies helps stakeholders work together

13. Centralized Policy
Management

14. GitSec
Centralized policies in versioned repositories
Use Git as repository
Methodology how to map repositories and branches to running software

15. 1. guard, watch
2. a watching, keeping watch
3. to keep watch
4. persons keeping watch, a guard, sentinels of the place where captives are kept, a prison of the time (of night) during which guard
was kept, a watch i.e., a period of time during which part of the guard was on duty, and at the end of which others relieved them
φυλακή
The tool set for GitSec

16. Policy Manager
K8s Adapter
Istio Adapter
... Adapter
Open Policy Adapter
Apps
K8s
Istio
...
POlPoliPolicy
Repository
Policy Checker
Master Data
Integration
Phylake High-Level Architecture

17. Uniform Real-Time
Policies

18. What Is the Open Policy Agent (OPA)?
The Open Policy Agent (OPA) is a cloud native real-time policy engine
CNCF project (Sandbox)
Can be deployed as a sidecar or standalone app
Integrations for common infrastructure components
The Rego language is an accessible formal policy language
Tooling for developing policies in Rego
http://www.openpolicyagent.org/
Unify as far as possible on Open Policies

19. Bridging Business and
Technical Policies

20. Business
Policies
Derived
Policies
Technical
Policies
“Be GoDB
compliant”
“Archive your
software”
Use the K8s
admission
controller to
trigger the
archiving
system

21. Business Policies
godb = true
hippa = false
stgb203 = false
gdpr = true
bsiC5 = true
coporateSecurityGuideline = true
k8sBestPractices = true

22. archivingRequired = compliance.godb
auditingRequired = any([compliance.godb, compliance.hippa,
compliance.bsiC5])
noSnapshots = any([compliance.godb, compliance.bsiC5,
compliance.coporateSecurityGuideline])
Derived Policies

23. deny["Invalid Git commit hash annotation" ] {
policies.archivingRequired
not re_match(`^[a-f0-9]{40}$`, gitCommitAnnotation (input))
}
deny[msg] {
policies.noSnapshots
endswith(containers(input)[i].image, ":latest")
msg = sprintf("No explicit image version for the container %s" ,
[containers(input)[i].name])
}
Technical Policies

24. Where do we stand
now?

25. Very rough outline of the GitSec methodology
Prototype implementation of Phylake in Go
Prototypical policy manager checker
Supports Kubernetes admission control and Istio network policies
Simple YAML business policy definitions
We are at the very beginning

26. Lessons Learned

27. Our ideas are sound and create value
The GitSec concepts need more love and much more detail
Open Policy is not widely supported yet
⇒ It makes sense to integrate component-specific policy definitions now and
converge on Open Policies later

28. Can I Take Part?

29. Absolutely!
We want Phylake to be community-driven Open Source (It isn’t, yet)
We’re still at the early stages
Take part, or just stay informed
Contact me: andreas.zitzelsberger@qaware.de
@andreasz82