Book Image

Kubernetes – An Enterprise Guide - Second Edition

By : Marc Boorshtein, Scott Surovich
Book Image

Kubernetes – An Enterprise Guide - Second Edition

By: Marc Boorshtein, Scott Surovich

Overview of this book

Kubernetes has taken the world by storm, becoming the standard infrastructure for DevOps teams to develop, test, and run applications. With significant updates in each chapter, this revised edition will help you acquire the knowledge and tools required to integrate Kubernetes clusters in an enterprise environment. The book introduces you to Docker and Kubernetes fundamentals, including a review of basic Kubernetes objects. You’ll get to grips with containerization and understand its core functionalities such as creating ephemeral multinode clusters using KinD. The book has replaced PodSecurityPolicies (PSP) with OPA/Gatekeeper for PSP-like enforcement. You’ll integrate your container into a cloud platform and tools including MetalLB, externalDNS, OpenID connect (OIDC), Open Policy Agent (OPA), Falco, and Velero. After learning to deploy your core cluster, you’ll learn how to deploy Istio and how to deploy both monolithic applications and microservices into your service mesh. Finally, you will discover how to deploy an entire GitOps platform to Kubernetes using continuous integration and continuous delivery (CI/CD).
Table of Contents (17 chapters)
15
Other Books You May Enjoy
16
Index

Mutating objects and default values

To this point, everything we have discussed has been about how to use Gatekeeper to enforce a policy. Kubernetes has another feature called mutating admission webhooks that allow a webhook to change, or mutate, an object before the API server processes it and runs validating admission controllers.

A common usage of a mutating webhook is to explicitly set security context information on pods that don't have it set. For instance, if you create a Pod with no spec.securityContext.runAsUser then the Pod will run as the user the Docker container was built to run as using the USER directive (or root by default) when it was built. This is insecure, since it means you could be running as root, especially if the container in question is from Docker Hub. While you can have a policy that blocks running as root, you could also have a mutating webhook that will set a default user ID if it's not specified to make it a default. This makes for a better...