RBAC, NetworkPolicies and PodSecurityPolicies

The basics of Kubernetes security through role based access control (RBAC), network policies and pod security policies. How do these things fit together? What are they used for?

Link to the demo material: https://github.com/lentzi90/kubernetes-training-material

Transcript

1. 1 RBAC, NetworkPolicies and PodSecurityPolicies Lennart Jern 12.12.2019
2. 2 • NetworkPolicies ◦ Simple example • RBAC ◦ Simple example • PodSecurityPolicies ◦ Who creates the Pod? ◦ Simple example • Demo time! Outline
3. 3 The firewalls of Kubernetes NetworkPolicies
4. 4 • Firewalls for Kubernetes. • Allow or deny traffic based on pod/namespace labels. • Depends on support from the network addon (e.g. Calico or Weave) NetworkPolicies
5. 5 Network policy example • A NetworkPolicy that only allows Pods to communicate with namespaces with the label `network: green`. • Applies to all pods in the blue namespace. • Affects both incoming and outgoing traffic. • For separation of duties, use RBAC to only allow network admins to create/modify namespaces and network policies. apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-green namespace: blue spec: podSelector: {} # Match everything! policyTypes: - Ingress # Affects incoming traffic - Egress # Affects outgoing traffic ingress: - from: - namespaceSelector: matchLabels: network: green egress: - to: - namespaceSelector: matchLabels: network: green
6. 6 RBAC: Who can do what? Role based access control
7. 7 • (Cluster)Roles: ◦ Permissions (the “what” in “who can do what”) • (Cluster)RoleBindings: ◦ Matches users, groups and service accounts to (Cluster)Roles (the “who”) • Scope: ◦ Roles and RoleBindings only work within a namespace ◦ ClusterRoles and ClusterRoleBindings work at the cluster level ◦ Possible to mix, e.g. ClusterRole + RoleBinding • Privilege escalation prevention ◦ Prevent users from giving more privileges than they already have Role based access control - RBAC
8. 8 RBAC example • The Role Deployer allows Deployments to be created, updated or patched. • The RoleBinding DeveloperDeployer binds the Role to user Dev. This simply means that user Dev is allowed to create, update and patch Deployments in the default namespace. apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: Deployer namespace: default rules: - apiGroups: [""] # "" indicates the core API group resources: ["deployments"] verbs: ["create", "update", "patch"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: DeveloperDeployer namespace: default subjects: - kind: User name: Dev # Name is case sensitive apiGroup: rbac.authorization.k8s.io roleRef: kind: Role # this must be Role or ClusterRole name: Deployer # must match name of the (Cluster)Role apiGroup: rbac.authorization.k8s.io
9. 9 What can Pods do? PodSecurityPolicies
10. 10 • PodSecurityPolicies: ◦ Permissions for Pods ◦ The Pod must have permission to “use” the PSP • Who creates the pod? Who needs to use the PSP? • What can we control? ◦ User ID of container processes ◦ Privileged mode ◦ Volume mounts ◦ SELinux ◦ AppArmor PodSecurityPolicies - What can Pods do?
11. 11 • CI/CD pipeline or developer creates a Deployment. ◦ The Deployment holds a reference to a ServiceAccount. ◦ Defaults to “default”, which is automatically created in every namespace. • Kubernetes uses a ServiceAccount to create a ReplicaSet for the current version of the Deployment. • Kubernetes uses a ServiceAccount to create Pods for the ReplicaSet. • Pods act through their ServiceAccounts and must be able to use a PSP matching their configuration. • The ServiceAccount referred to in the Deployment must be able to run the Pods. Who creates the Pod?
12. 12 • root: a PSP that allows running as root • sudo: a Role that allows using the root PSP • sudoer: a RoleBinding that binds the default ServiceAccount in the default namespace to use the sudo role. PodSecurityPolicy example apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: root spec: privileged: false # Don't allow privileged pods seLinux: rule: RunAsAny supplementalGroups: rule: RunAsAny runAsUser: rule: RunAsAny # But allow running as root! fsGroup: rule: RunAsAny volumes: ['configMap', 'emptyDir', 'projected', 'secret', 'downwardAPI', 'persistentVolumeClaim'] apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: sudo namespace: default rules: - apiGroups: ["policy"] resources: ["podsecuritypolicy"] resourceName: ["root"] # Only allow this specific PSP verbs: ["use"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: sudoer subjects: - kind: ServiceAccount # Not a User name: default namespace: default roleRef: kind: Role name: sudo apiGroup: rbac.authorization.k8s.io
13. 13 Demo material Demo time!