This topic is weighed 12% on exam
Know how to configure authentication and authorization
- Authenticating https://kubernetes.io/docs/admin/authentication/
- First API server needs to authenticate the client sending the request. This is performed by one or more authentication plugins. API server calls plugins in turn until one of them determines who is sending the request. Depending on authenticate method, user can be extracted from client cert or HTTP header. Plugin extracts client’s username, user ID, and groups user belongs do. This data is then used in next state, authorization
- Authorization https://kubernetes.io/docs/admin/authorization/
- API server configured to use one or more authorization plugins. Their job is to determine whether authenticated user can perform the requested action on requested resource. e.g. when created pods, API server consults authorization plugins in turn, to determine whether user can create pods in the requested namespace. As soon as plugin says the user can perform action, API server progresses to next state, Admission control
- Admission Control https://kubernetes.io/docs/admin/admission-controllers/
- If request is to create, modify, or delete resource, request sent through admission control. Server is configured with multiple admission control plugins. They may modify resource or reject request for whatever reason, then the resource passes through all the admission control plugins
- If request is only trying to read data, request doesn’t go through admission control
- After request passes through all admission control plugins, API server validates object, stores it in etcd, and returns response to client
Understand Kubernetes security primitives
- service accounts - the account that the pod authenticates as when talking to the API server.
Know how to configure network policies
- govern how pods communicate with one another
- CNI must support network policy
Create and manage TLS certificates for cluster components
Certifik8s: All You Need to Know About Certificates in Kubernetes https://www.youtube.com/watch?v=gXz4cq3PKdg
- Cluster CA - trusted root for entire cluster; all cluster certificates are signed by cluster CA; allow all components to authenticate each other
- API Server - serving certificate signed by CA; has client certificate like other kubernetes components
- Kubelet - expose API over HTTPS; serving certificate signed by CA; each kubelet has its own identity
- X.509 Client Cert Authentication - authenticating requests that present client certificate; user cn, and groups from org field obtained from cert
- Kubernetes offers API to request certs
- Certificates in use on component layer in kubernetes cluster
Work with images securely
- Ensure images are free of vulnerabilities
- Implement Continuous Security Vulnerability Scanning – Containers might include outdated packages with known vulnerabilities (CVEs). This cannot be a ‘one off’ process, as new vulnerabilities are published every day. An ongoing process, where images are continuously assessed, is crucial to insure a required security posture.
- Regularly Apply Security Updates to Your Environment – Once vulnerabilities are found in running containers, you should always update the source image and redeploy the containers. Try to avoid direct updates (e.g. ‘apt-update’) to the running containers, as this can break the image-container relationship. Upgrading containers is extremely easy with the Kubernetes rolling updates feature - this allows gradually updating a running application by upgrading its images to the latest version.
- Ensure That Only Authorized Images are Used in Your Environment
- Use private registries to store your approved images - make sure you only push approved images to these registries.
Define security contexts - A security context is a property defined in yaml. A security context defines privilege and access control settings for a Pod or Container.
Secure persistent key value store
- You don’t want sensitive information such as a database password or an API key kept around in clear text. Secrets provide you with a mechanism to use such information in a safe and reliable way with the following properties:
- Secrets are namespaced objects, that is, exist in the context of a namespace
- You can access them via a volume or an environment variable from a container running in a pod
- The secret data on nodes is stored in tmpfs volumes
- A per-secret size limit of 1MB exists
- The API server stores secrets as plaintext in etcd
Work with role-based access control
- This gives all service accounts (we could also say all pods) cluster-admin privileges, allowing them to do whatever they want. (insecure). This is the simplest way to allow you to query the API server is to work around RBAC:
kubectl create clusterrolebinding permissive-binding --clusterrole=cluster-admin --group=system:serviceaccounts
- RBAC prevents unauthorized users from viewing or modifying the cluster state
- RBAC, which runs inside the API server, determines whether a client is allowed to perform the requested verb (get, create, update) on the requested resource or not.
- Besides applying security permissions to whole resource types, RBAC rules can also apply to specific instances of a resource (for example, a Service called myservice).
- The RBAC authorization plugin, as the name suggests, uses user roles as the key factor in determining whether the user may perform the action or not. A subject (which may be a human, a ServiceAccount, or a group of users or ServiceAccounts) is associated with one or more roles and each role is allowed to perform certain verbs on certain resources
- The RBAC authorization rules are configured through four resources, which can be grouped into two groups:
- Roles and ClusterRoles, which specify which verbs can be performed on which resources.
- RoleBindings and ClusterRoleBindings, which bind the above roles to specific users, groups, or ServiceAccounts.
- Roles define what can be done, while bindings define who can do it
- Role and RoleBinding are namespaced resources, whereas the ClusterRole and ClusterRoleBinding are cluster-level resources (not namespaced
- Service Account - Every pod is associated with a Service-Account, which represents the identity of the app running in the pod