From Policy to Production - Implementing ISO27001/BSI IT-Grundschutz in Kubernetes with Kyverno

Transcript

1. From Policy to Production Implementing ISO27001/BSI IT-Grundschutz in Kubernetes with Kyverno Version: 1.7.2 Marcus Ross From Policy to Production
2. Agenda Intro & Guidelines Standards & Kyverno Summary & Learnings From Policy to Production 2
3. Who apiVersion: v1 kind: Human metadata: name: "Marcus Ross" namespace: "Hamburg" spec: hobbies: ['triathlon','movies','3dprint'] job: "CCoE Lead" employer: "Hamburg Port Authority" certifications: - Kubestronaut - BSI-Vorfallpraktiker / ITIL-Expert - AWS-Champion / Architect social: linkedIn: linkedin.com/in/zahlenhelfer github: zahlenhelfer.github.com From Policy to Production 3
4. Hamburg Port HPA is responsible for the quays, roads, bridges and the dredging of the fairway. rail, inland waterway, lorry Germany's largest seaport Europe's largest rail port From Policy to Production 4
5. Digital world guidelines BSI Standards Methodology for information security management systems (ISMS) Covers technical, organisational, infrastructural and personnel aspects in equal measure Systematic approach to information security Is compatible to ISO/IEC 27001. Source: Website BSI From Policy to Production 5
6. ISO 27001 certification on the basis of IT-Grundschutz Possible via IT-Grundschutz (Standard or Core Protection levels). Requires audit by a BSI-certified ISO 27001 auditor. Includes document review, on-site audit, and submission of audit report to BSI. Certification is issued based on BSI’s review of the audit report. From Policy to Production 6
7. Let´s do it From Policy to Production 7
8. Chapter APP4.4 - Kubernetes 21 building blocks for k8s Specific criterias to check Chapter SYS 1.6 is for Containers Source: IT-Grundschutz-Compendium From Policy to Production 8
9. Three examples - Quick & Powerful APP.4.4.A7 - Separation of Networks for Kubernetes APP.4.4.A13 - Automated Configuration Auditing APP.4.4.A21 - Regular Restart of Pods From Policy to Production 9
10. APP.4.4.A7 - Separation of Networks for Kubernetes Networks for the administration of nodes, the control plane, and the individual networks of application services SHOULD be separated. Only the network ports of the pods necessary for operation SHOULD be released into the designated networks. If a Kubernetes cluster contains multiple applications, all the network connections between the Kubernetes namespaces SHOULD first be prohibited and only required network connections permitted (whitelisting). The network ports necessary for the administration of the nodes, the runtime, and Kubernetes (including its extensions) SHOULD ONLY be accessible from the corresponding administration network and from pods that need them. Only selected administrators SHOULD be authorised in Kubernetes to manage the CNI and create or change rules for the network. From Policy to Production 10
11. APP.4.4.A7 - Separation of Networks for Kubernetes (Standard) Physical networks of the nodes k8s internal overlay network From Policy to Production 11
12. physical Network Pod- Overlay node pod Frontend pod Backend pod REST-API pod HR-App pod DB Worker 1 node node Worker 2 Worker 3 Namespace WebApp Namespace HRApp Part a Part b APP.4.4.A7 - proposed solution Firewalls/Switches/VLans (Part a) Use of k8s network policies (Part b) From Policy to Production 12
13. Network-Policy apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-all spec: podSelector: {} policyTypes: - Ingress - Egress From Policy to Production 13
14. Kyverno approach Policy enforcement Use of generate: Create a ClusterPolicy - Gist-Link apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: generate-default-network-policy From Policy to Production 14
15. Kyverno Cluster-Policy with generate (deprecated) 1/2 apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: generate-default-network-policy annotations: policies.kyverno.io/title: Generate Default Network Policy policies.kyverno.io/category: Multi-Tenancy policies.kyverno.io/severity: medium policies.kyverno.io/description: >- This policy automatically generates a default NetworkPolicy in each namespace. spec: rules: - name: generate-default-deny-ingress-network-policy match: any: - resources: kinds: - Namespace ... next page ... From Policy to Production 15
16. Kyverno Cluster-Policy with generate (deprecated) 2/2 ... generate: generateExisting: true kind: NetworkPolicy apiVersion: networking.k8s.io/v1 name: default-deny-ingress namespace: "{{request.object.metadata.name}}" synchronize: true data: metadata: name: default-deny spec: podSelector: {} policyTypes: - Ingress ingress: [] From Policy to Production 16
17. Kyverno GeneratingPolicy 1/2 apiVersion: policies.kyverno.io/v1alpha1 kind: GeneratingPolicy metadata: name: add-networkpolicy ... spec: evaluation: synchronize: enabled: true matchConstraints: resourceRules: - apiGroups: - "" apiVersions: - v1 operations: - CREATE - UPDATE resources: - namespaces From Policy to Production 17
18. Kyverno GeneratingPolicy 2/2 variables: - name: targetNs expression: object.metadata.name - name: downstream expression: |- [ { "kind": dyn("NetworkPolicy"), "apiVersion": dyn("networking.k8s.io/v1"), "metadata": dyn({ "name": "default-deny", }), "spec": dyn({ "podSelector": dyn({}), "policyTypes": dyn(["Ingress", "Egress"]) }) } ] generate: - expression: generator.Apply(variables.targetNs, variables.downstream) From Policy to Production 18
19. Cross-Reference: IT-Grundschutz <-> ISO27001 ISO/IEC 27001:2022 Control IT-Grundschutz APP.4.4.A7 A.8.22 - Segregation of Networks Core match A.8.20 - Networks Security Broad network security governance A.8.26 - Application Security Requirements App-layer traffic control A.5.15 - Access Control Least-privilege for network paths A.8.21 - Security of Network Services Securing services on the network From Policy to Production 19
20. APP.4.4.A13 - Automated Configuration Auditing There SHOULD be an automated audit that checks the settings of nodes, of Kubernetes, and of the pods of applications against a defined list of allowed settings and standardised benchmarks. Kubernetes SHOULD enforce these established rules in each cluster by connecting appropriate tools. From Policy to Production 20
21. Is Kyverno the right tool for that? APP.4.4.A13 Kyverno Coverage Audit API-level configurations Yes, natively Audit node-level configuration No Audit-proof logging of results Via PolicyReports Continuous background scanning Yes Regular automated checks Yes From Policy to Production 21
22. APP.4.4.A13 - proposed solution use a defined list of allowed settings could be the Kubernetes CIS-Benchmark (v.11.1/2.0.0) create Policies against these items (ex. 5.2) use enforce instead of audit From Policy to Production 22
23. Example: CIS 5.2.2 / 5.2.3 / 5.2.4 Privileged Containers / Capabilities / HostPID ... validate: message: "CIS 5.2.2: Privileged containers are not allowed" pattern: spec: =(containers): - =(securityContext): =(privileged): false =(initContainers): - =(securityContext): =(privileged): false ... From Policy to Production 23
24. LifeHack: do match any and exclude # hardcoded list exclude: any: - resources: namespaces: - kube-system - kyverno - default # label based list namespaceSelector: matchExpressions: - key: "kyverno.io/exclude" operator: NotIn values: ["true"] From Policy to Production 24
25. APP.4.4.A21 - Regular Restart of Pods (High) No pod SHOULD run longer than 24 hours. Availability of the applications in a pod SHOULD be ensured From Policy to Production 25
26. APP.4.4.A21 - proposed solution Google search yielded nothing! Own development in Golang - Operator or CronJob? ... and then there was the KCA-Exam From Policy to Production 26
27. ...but Kyverno can do this, too Enable by using labels cleanup.kyverno.io/ttl Gist-Link apiVersion: apps/v1 kind: Deployment metadata: name: foo labels: cleanup.kyverno.io/ttl: 24h From Policy to Production 27
28. Summary & Learnings You saw three examples - start small and evolve continuously Kyverno is helpful, but it's not the only consideration It´s a hidden champion in your daily business IT-Grundschutz/ISO27001 is not an end in itself From Policy to Production 28
29. Hamburg Port Authority - "Port is what we do" From Policy to Production 29