observability, … ◦ Developers can focus more on application logic ◦ Developer can work more productively • For example ◦ Enhance CI security ◦ Introduce HPA with External metrics / VPA ◦ Visualize Infra Cost ◦ etc • Enhancing kubernetes security is also our responsibility
are increasing ◦ Can’t put all security responsibility on the developers • It is our responsibility to ensure we have basic guardrails in our system. To resolve that, we introduced Gatekeeper
General-purpose policy engine hosted by OPA (Open Policy Agent) • We can create policies in its own language called Rego ◦ For example ▪ Enforce pods to have resource limits ▪ Restrict the addition of Linux capabilities to containers ▪ Limit the container registries to only allowed certain ones
and mitigations Policies that we implemented to enforce security best practices in our Kubernetes workloads: • Prevent adding extra capabilities • Restrict the usage of the host network • Prevent containers from running in privileged mode
capabilities • Docker has already blocked some capabilities such as SYS_ADMIN, NET_ADMIN, and so on ◦ but thoughtlessly adding other capabilities will have unexpected security risks ◦ Whitelist some components • Related CVE: CVE-2020-14386 ◦ Allows escape from a container to obtain root privileges ◦ This is related to CAP_NET_RAW ▪ Enables ARP (Address Resolution Protocol) spoofing attacks
capabilities • This policy checks PodSpec definitions in all Pod, Deployment, DaemonSet, and so on ◦ Checks `.spec.containers[].securityContext.capabilities.add`
of the host network • Containers using the host network can do many things to jeopardize our cluster ◦ Allow processes in the pod to talk on the host’s loopback adapter ◦ Create port conflicts with other containers • Related CVE: CVE-2020-15257 ◦ containerd containers running in the host network namespaces with UID 0 allowed to gain the host root privileges
of the host network • This policy checks PodSpec definitions in all Pod, Deployment, DaemonSet, and so on ◦ limits the value of `.spec.hostNetwork` to false
running in privileged mode • Privileged mode allows container processes to access host devices ◦ Enables processes to behave like host processes (running outside a container) ◦ Allows bypassing almost all Kubernetes and Docker security controls
running in privileged mode • This policy checks PodSpec definitions in all Pod, Deployment, DaemonSet, and so on ◦ limits the value of `.spec.containers[].securityContext.privileged` to false
these Gatekeeper policies which are helping us in keeping security best practices • Related to ◦ host-path volumes ◦ host namespaces ◦ Istio ◦ node pool access ◦ etc
deploying services to the Kubernetes in the development environment ◦ Automatic and continuous security checks during the deployment phase of the development cycle ◦ Can find and fix problems early on in your daily development ◦ Speeds up releases • Fundamental idea in DevSecOps: Shift-Left-Security
us from the planning stage ◦ We proceeded with the plan under their review • The collaboration between our platform team and the security team is essential to promote DevSecOps
our platform wide guardrails ◦ Dedicated node-pool for a namespace ◦ Restrict developers from using alpha release features ◦ Force the developer to use a specific option for reliability or performance ▪ VPA: Enforces developers to specify a lower bound of request resources ▪ Enforce to write resource limits
Your Podcast. Everywhere. Effortlessly.
moricho
pauljervisheath
cassininazir
csswizardry
ipullrank
dougneiner
chriscoyier
carmenintech
.jpg){kind=avatar}
cargoodrich
soudai
codingconduct
aemeredith
tmiket
