deprecate DenyExecOnPrivileged/DenyEscalatingExec (#12152)
parent
64fc415cdd
commit
079a91fe79
|
@ -4,6 +4,8 @@ date: 2016-08-31
|
|||
slug: security-best-practices-kubernetes-deployment
|
||||
url: /blog/2016/08/Security-Best-Practices-Kubernetes-Deployment
|
||||
---
|
||||
_Note: some of the recommendations in this post are no longer current. Current cluster hardening options are described in this [documentation](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/)._
|
||||
|
||||
_Editor’s note: today’s post is by Amir Jerbi and Michael Cherny of Aqua Security, describing security best practices for Kubernetes deployments, based on data they’ve collected from various use-cases seen in both on-premises and cloud deployments._
|
||||
|
||||
Kubernetes provides many controls that can greatly improve your application security. Configuring them requires intimate knowledge with Kubernetes and the deployment’s security requirements. The best practices we highlight here are aligned to the container lifecycle: build, ship and run, and are specifically tailored to Kubernetes deployments. We adopted these best practices in [our own SaaS deployment](http://blog.aquasec.com/running-a-security-service-in-google-cloud-real-world-example) that runs Kubernetes on Google Cloud Platform.
|
||||
|
|
|
@ -142,20 +142,24 @@ if the pods don't already have toleration for taints
|
|||
|
||||
This admission controller will intercept all requests to exec a command in a pod if that pod has a privileged container.
|
||||
|
||||
If your cluster supports privileged containers, and you want to restrict the ability of end-users to exec
|
||||
commands in those containers, we strongly encourage enabling this admission controller.
|
||||
|
||||
This functionality has been merged into [DenyEscalatingExec](#denyescalatingexec).
|
||||
The DenyExecOnPrivileged admission plugin is deprecated and will be removed in v1.18.
|
||||
|
||||
### DenyEscalatingExec {#denyescalatingexec}
|
||||
Use of a policy-based admission plugin (like [PodSecurityPolicy](#podsecuritypolicy) or a custom admission plugin)
|
||||
which can be targeted at specific users or Namespaces and also protects against creation of overly privileged Pods
|
||||
is recommended instead.
|
||||
|
||||
### DenyEscalatingExec (deprecated) {#denyescalatingexec}
|
||||
|
||||
This admission controller will deny exec and attach commands to pods that run with escalated privileges that
|
||||
allow host access. This includes pods that run as privileged, have access to the host IPC namespace, and
|
||||
have access to the host PID namespace.
|
||||
|
||||
If your cluster supports containers that run with escalated privileges, and you want to
|
||||
restrict the ability of end-users to exec commands in those containers, we strongly encourage
|
||||
enabling this admission controller.
|
||||
The DenyEscalatingExec admission plugin is deprecated and will be removed in v1.18.
|
||||
|
||||
Use of a policy-based admission plugin (like [PodSecurityPolicy](#podsecuritypolicy) or a custom admission plugin)
|
||||
which can be targeted at specific users or Namespaces and also protects against creation of overly privileged Pods
|
||||
is recommended instead.
|
||||
|
||||
### EventRateLimit (alpha) {#eventratelimit}
|
||||
|
||||
|
|
Loading…
Reference in New Issue