RBAC, NetworkPolicies and PodSecurityPolicies

Learn more about the security fundamentals of Kubernetes and how they fit together!

Training/demo material: https://github.com/lentzi90/kubernetes-training-material

Transcript

1. 1 RBAC, NetworkPolicies and PodSecurityPolicies Lennart Jern 21.02.2020
2. 2 • NetworkPolicies ◦ Simple example • RBAC ◦ Simple example ◦ Privilege escalation prevention • 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 $ # Create a role that allows creating rolebindings $ kubectl create role test --verb=get,list,create,delete,patch,update --resource=rolebindings $ # Bind user lennart to the role $ kubectl create rolebinding test --role=test --user=lennart $ # Try to grant admin privileges to lennart while impersonating lennart $ kubectl create rolebinding hack --clusterrole=admin --user=lennart --as=lennart Error from server (Forbidden): rolebindings.rbac.authorization.k8s.io "hack" is forbidden: user "lennart" (groups=["system:authenticated"]) is attempting to grant RBAC permissions not currently held: ... Privilege escalation prevention
10. 10 What can Pods do? PodSecurityPolicies
11. 11 • 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?
12. 12 • 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?
13. 13 • 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
14. 14 Demo material Demo time!