Securing Kubernetes Workloads
1 like526 views
The document outlines best practices for securing Kubernetes workloads, covering key components such as secret management, access controls, and network policies. It emphasizes the importance of using policy engines like Kyverno for managing configurations and suggests utilizing management planes like Nirmata for effective Kubernetes configuration. Overall, it highlights the necessity of implementing robust security measures across different cluster components for optimal protection of workloads.
Securing Kubernetes Workloads
- 1. Securing Kubernetes Workloads Best Practices for Securing Kubernetes Workload Configurations Across Clouds Jim Bugwadia Founder and CEO
- 2. Agenda • Kubernetes Security Framework • Kubernetes Constructs for Workload Security • Q & A 2
- 3. 3 About me • @JimBugwadia • Founder and CEO at Nirmata • Working on large-scale distributed systems (C++, Java, JS, Go) since 1994 CKA-1700-0169-0100
- 4. 4 Kubernetes Security Framework Build Operate Container Hosts: ❑ Minimal OS ❑ OS Hardening ❑ CIS Benchmarks Clusters: ❑ RBAC ❑ Audit Policies and Logging ❑ Certificate Management ❑ Identity and Access ❑ Kubernetes upgrades ❑ CIS Benchmarks Applications: ❑ Image scanning ❑ Image Provenance ❑ Secrets Management ❑ Namespaces ❑ Access Controls ❑ Network Policies ❑ Resource Quotas ❑ Pod Security Policy
- 5. 5 Kubernetes Security Framework Build Operate Container Hosts: ❑ Minimal OS ❑ OS Hardening ❑ CIS Benchmarks Clusters: ❑ RBAC ❑ Audit Policies and Logging ❑ Certificate Management ❑ Identity and Access ❑ Kubernetes upgrades ❑ CIS Benchmarks Applications: ❑ Image scanning ❑ Image Provenance ❑ Secrets Management ❑ Namespaces ❑ Access Controls ❑ Network Policies ❑ Resource Quotas ❑ Pod Security Policy
- 7. 7 Image Provenance • Image scanning checks images for vulnerabilities o Ideally done when the image is built and before it is accepted into the image registry • Image provenance 1. Confirms that an image being deployed is from a trusted source 2. Confirms that image has not been not tampered with
- 8. 8 Image Provenance - Solutions • Kubernetes ImagePolicyWebhook o Configured as an admission controller o Sends an ImageReview request o Expects an ImageReview response of accept or deny
- 9. 9 Image Provenance - Solutions • Portieris o Also an admission controller o Integrates with Notary (a content trust store) – part of the The Update Framework (TUF) o Provides way to specify image security policies at a namespace and cluster level https://github.com/IBM/portieris https://theupdateframework.github.io/ https://github.com/theupdateframework/notary
- 10. 10 Image Provenance – Partial Solutions • Kyverno o Also an admission controller o Kubernetes Native Policy Engine o Policies are written as overlay rules https://kyverno.io/ https://thenewstack.io/kyverno-kubernetes-configuration-via-policy/
- 11. 11 Image Provenance – Partial Solutions • OPA / Gatekeeper o Also an admission controller o General Purpose Policy Engine o Policies are written in Rego https://www.openpolicyagent.org/ https://github.com/open-policy-agent/gatekeeper https://medium.com/capital-one-tech/policy-enabled-kubernetes-with-open-policy-agent-3b612b3f0203
- 13. 13 Secrets • Any sensitive data that an application needs o Passwords o Certificates o Keys o …
- 14. 14 Secrets Management Anti-Patterns (please try not to do this) x Hard-coded x Packaged with code x Inserted via build tools x Environment Variables
- 15. 15 What Kubernetes Provides • API Object to define secrets • Values are base 64 encoded (default) • Secrets are namespaced • Secrets can be mounted as volumes • Secrets can be used as environment variables • Encryption can be configured at the API Server apiVersion: v1 kind: Secret metadata: name: mysecret type: Opaque data: username: YWRtaW4=
- 16. 16 So, what’s missing? Kubernetes secrets are a step forward, but have a few limitations: • Encryption requires configuring static keys or a KMS • Shared (static) approach • No leases, rotation, etc.
- 17. 17 Secrets Management with Hashicorp Vault • Helps automates security best practices for o Secrets Management o Auditing o Certificate Management o Encryption • Dynamic Secrets o Credentials (keys, passwords, certificates) are generated when a client requests them o Credentials are per client o Credentials are automatically deleted if a lease expires
- 18. 18 An init container to fetch secrets init container Vault Kubernetes Pod application container Service Account & Role Secrets … Volume (secret) https://github.com/nirmata/kube-vault-client https://www.nirmata.com/2018/12/19/managing-kubernetes-secrets-with-hashicorp-vault-and-nirmata/
- 19. Namespaces 19
- 20. 20 Namespaces • Kubernetes Data Plane Virtualization • Namespaces partition the Kubernetes object model so multiple objects with the same name can exist in the same cluster • Namespaces are the foundation for applying other security constructs Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called namespaces. https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/
- 22. 22 Role-based access control (RBAC) • Users are authenticated via OIDC, X.509 certificates, tokens, etc. • The authentication result can provide user and group information. • However, Users and User Groups are managed externally (e.g. in an LDAP / AD server). • Kubernetes has a fine-grained permission model • Role (namespace) / ClusterRole • Roles are mapped to users or groups via role bindings • RoleBinding (namespace) / ClusterRoleBinding
- 23. 23 Service Accounts • Service Accounts are meant for authenticating and authorizing processes • Each namespace has a default service account • Each Pod has a service account (default – if not specified) • A best practice is to use a service account per app • To prevent a service account token from being mounted in a Pod use “automountServiceAccountToken: false”. This can be enforced via a policy.
- 25. 25 Network Segmentation via Network Policies • By default, Kubernetes pods are “non-isolated” • They accept network connections from any source and can initiate connection requests to any destination • Network Policies define traffic rules for Kubernetes pods • ingress (inbound traffic) • egress (outbound traffic) Network Policy Pod Selector Ingress Ingress Rule Ingress Rule Ingress Rule Egress Ingress Rule Ingress Rule Egress Rule
- 27. 27 Resource Management • Pods can have resource requests and limits • This allows three quality of service models GuaranteedBurstable • A namespace can have limits and default allocations • Quotas and limits ensure fairness and stability https://opensource.com/article/18/12/optimizing- kubernetes-resource-allocation-production
- 29. 29 Pod Security Policies • Controls runtime security settings for pods • Enabled at the API Controller • Requires a role binding between pod Service Account and the PSP
- 30. 30 Use a policy engine to audit and enforce • Pod Security Policies are tricky to manage o Require a role binding to SA o Applied in alphabetical order • Kyverno supports enforcement of the important PSP checks https://github.com/nirmata/kyverno/tree/master/ examples/best_practices
- 31. Summary 31
- 32. 32
- 33. 33 Summary 1. Kubernetes provides several constructs for workload security 2. Use a Policy Engine like Kyverno to simplify management of configurations 3. Use a management plane like Nirmata to configure Kubernetes correctly https://kyverno.io/ https://nirmata.com/
- 34. 34 Nirmata – The Kubernetes Management Plane Kubernetes Components, Services, and Workloads K8s Data Center K8s Clouds K8s Edge Service Mgmt VisibilityGovernance Compliance Optimization The Nirmata Platform Change Mgmt. Audit Logs Health Capacity Isolation Policies TuningDiscovery Any Infrastructure Nirmata Cloud or Private Edition Any App