deprecate DenyExecOnPrivileged/DenyEscalatingExec #12152

liggitt · 2019-01-09T17:06:24Z

Update guidance for admission plugins

liggitt · 2019-01-09T17:08:11Z

content/en/blog/_posts/2016-08-00-Security-Best-Practices-Kubernetes-Deployment.md

@@ -205,7 +205,15 @@ Reference [here](http://kubernetes.io/docs/api-reference/v1/definitions/#_v1_pod





wasn't sure how revisionist we get about blog post updates, but this advice isn't current

The ResourceQuota section is incorrect, also

Maybe just mark the blog post as being out of date and containing errors?

k8sio-netlify-preview-bot · 2019-01-09T17:11:41Z

Deploy preview for kubernetes-io-master-staging ready!

Built with commit 2b3c150

https://deploy-preview-12152--kubernetes-io-master-staging.netlify.com

bgrant0607

The admission-control update looks good to me.
/lgtm

bgrant0607 · 2019-01-18T18:18:43Z

content/en/blog/_posts/2016-08-00-Security-Best-Practices-Kubernetes-Deployment.md

@@ -205,7 +205,15 @@ Reference [here](http://kubernetes.io/docs/api-reference/v1/definitions/#_v1_pod





The ResourceQuota section is incorrect, also

bgrant0607 · 2019-01-18T18:19:15Z

content/en/blog/_posts/2016-08-00-Security-Best-Practices-Kubernetes-Deployment.md

@@ -205,7 +205,15 @@ Reference [here](http://kubernetes.io/docs/api-reference/v1/definitions/#_v1_pod





Maybe just mark the blog post as being out of date and containing errors?

zparnold · 2019-02-13T11:25:43Z

content/en/blog/_posts/2016-08-00-Security-Best-Practices-Kubernetes-Deployment.md

+running privileged containers.
+
+If you do not want all users with the ability to create a pod to have root-level access to nodes,
+you should consider using a policy-based admission plugin to limit the types of pods that can be created.


Suggested change

you should consider using a policy-based admission plugin to limit the types of pods that can be created.

you should consider using a policy-based admission plugin to limit the types of Pods that can be created.

zparnold · 2019-02-13T11:25:43Z

content/en/blog/_posts/2016-08-00-Security-Best-Practices-Kubernetes-Deployment.md

+access to the nodes they run on, including mounting arbitrary host paths, running as root, and
+running privileged containers.
+
+If you do not want all users with the ability to create a pod to have root-level access to nodes,


Suggested change

If you do not want all users with the ability to create a pod to have root-level access to nodes,

If you do not want all users with the ability to create a Pod to have root-level access to nodes,

zparnold · 2019-02-13T11:25:45Z

content/en/blog/_posts/2016-08-00-Security-Best-Practices-Kubernetes-Deployment.md

@@ -205,7 +205,15 @@ Reference [here](http://kubernetes.io/docs/api-reference/v1/definitions/#_v1_pod



-In case you are running containers with elevated privileges (--privileged) you should consider using the “DenyEscalatingExec” admission control. This control denies 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. For more details on admission controls, see the Kubernetes [documentation](http://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/).
+By default, users with the ability to create pods can make use of features that allow root-level 
+access to the nodes they run on, including mounting arbitrary host paths, running as root, and


Suggested change

access to the nodes they run on, including mounting arbitrary host paths, running as root, and

access to the Nodes they run on, including mounting arbitrary host paths, running as the `root` user, and

zparnold · 2019-02-13T11:25:45Z

content/en/blog/_posts/2016-08-00-Security-Best-Practices-Kubernetes-Deployment.md

@@ -205,7 +205,15 @@ Reference [here](http://kubernetes.io/docs/api-reference/v1/definitions/#_v1_pod



-In case you are running containers with elevated privileges (--privileged) you should consider using the “DenyEscalatingExec” admission control. This control denies 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. For more details on admission controls, see the Kubernetes [documentation](http://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/).
+By default, users with the ability to create pods can make use of features that allow root-level 


Suggested change

By default, users with the ability to create pods can make use of features that allow root-level

By default, users with the ability to create Pods can make use of features that allow root-level

content/en/docs/reference/access-authn-authz/admission-controllers.md

zparnold · 2019-02-13T11:28:04Z

@liggitt Small nits, also great to see you again! Let me know if you (dis)agree. I made them as suggestions, so you should just be able to accept them if they work.

liggitt · 2019-02-13T23:12:22Z

/hold cancel

liggitt · 2019-02-13T23:13:07Z

@zparnold made the suggested changes inline, and reverted the blog post content changes in favor of a note at the top pointing to latest cluster hardening guides.

Rajakavitha1 · 2019-02-17T12:26:18Z

@zparnold Please take a look and state your approval.

zparnold · 2019-02-17T16:03:09Z

/lgtm
/approve

k8s-ci-robot · 2019-02-17T16:03:21Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: zparnold

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

~~content/en/OWNERS~~ [zparnold]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

k8s-ci-robot added do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. size/S Denotes a PR that changes 10-29 lines, ignoring generated files. labels Jan 9, 2019

liggitt mentioned this pull request Jan 9, 2019

Deprecate DenyEscalatingExec and DenyExecOnPrivileged admission plugins kubernetes/kubernetes#72737

Merged

k8s-ci-robot added the language/en Issues or PRs related to English language label Jan 9, 2019

k8s-ci-robot requested review from janetkuo and kbarnard10 January 9, 2019 17:06

liggitt commented Jan 9, 2019

View reviewed changes

bgrant0607 reviewed Jan 18, 2019

View reviewed changes

k8s-ci-robot assigned bgrant0607 Jan 18, 2019

k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Jan 18, 2019

zparnold reviewed Feb 13, 2019

View reviewed changes

content/en/docs/reference/access-authn-authz/admission-controllers.md Outdated Show resolved Hide resolved

zparnold reviewed Feb 13, 2019

View reviewed changes

content/en/docs/reference/access-authn-authz/admission-controllers.md Outdated Show resolved Hide resolved

deprecate DenyExecOnPrivileged/DenyEscalatingExec

2b3c150

liggitt force-pushed the deny-exec branch from b935ec7 to 2b3c150 Compare February 13, 2019 23:12

k8s-ci-robot removed the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Feb 13, 2019

k8s-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Feb 13, 2019

k8s-ci-robot assigned zparnold Feb 17, 2019

k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Feb 17, 2019

k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Feb 17, 2019

k8s-ci-robot merged commit 079a91f into kubernetes:master Feb 17, 2019

kwiesmueller pushed a commit to kwiesmueller/website that referenced this pull request Feb 28, 2019

deprecate DenyExecOnPrivileged/DenyEscalatingExec (kubernetes#12152)

d530375

krmayankk pushed a commit to krmayankk/kubernetes.github.io that referenced this pull request Mar 11, 2019

deprecate DenyExecOnPrivileged/DenyEscalatingExec (kubernetes#12152)

e92c729

yagonobre pushed a commit to yagonobre/website that referenced this pull request Mar 14, 2019

deprecate DenyExecOnPrivileged/DenyEscalatingExec (kubernetes#12152)

21eae82

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

deprecate DenyExecOnPrivileged/DenyEscalatingExec #12152

deprecate DenyExecOnPrivileged/DenyEscalatingExec #12152

liggitt commented Jan 9, 2019

liggitt Jan 9, 2019

bgrant0607 Jan 18, 2019

bgrant0607 Jan 18, 2019

k8sio-netlify-preview-bot commented Jan 9, 2019 •

edited by netlify bot

bgrant0607 left a comment

bgrant0607 Jan 18, 2019

bgrant0607 Jan 18, 2019

zparnold Feb 13, 2019

zparnold Feb 13, 2019

zparnold Feb 13, 2019

zparnold Feb 13, 2019

zparnold commented Feb 13, 2019

liggitt commented Feb 13, 2019

liggitt commented Feb 13, 2019 •

edited

Rajakavitha1 commented Feb 17, 2019

zparnold commented Feb 17, 2019

k8s-ci-robot commented Feb 17, 2019

		@@ -205,7 +205,15 @@ Reference [here](http://kubernetes.io/docs/api-reference/v1/definitions/#_v1_pod

	you should consider using a policy-based admission plugin to limit the types of pods that can be created.
	you should consider using a policy-based admission plugin to limit the types of Pods that can be created.

	If you do not want all users with the ability to create a pod to have root-level access to nodes,
	If you do not want all users with the ability to create a Pod to have root-level access to nodes,

	access to the nodes they run on, including mounting arbitrary host paths, running as root, and
	access to the Nodes they run on, including mounting arbitrary host paths, running as the `root` user, and

		@@ -205,7 +205,15 @@ Reference [here](http://kubernetes.io/docs/api-reference/v1/definitions/#_v1_pod



		In case you are running containers with elevated privileges (--privileged) you should consider using the “DenyEscalatingExec” admission control. This control denies 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. For more details on admission controls, see the Kubernetes [documentation](http://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/).
		By default, users with the ability to create pods can make use of features that allow root-level

deprecate DenyExecOnPrivileged/DenyEscalatingExec #12152

deprecate DenyExecOnPrivileged/DenyEscalatingExec #12152

Conversation

liggitt commented Jan 9, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

k8sio-netlify-preview-bot commented Jan 9, 2019 • edited by netlify bot

bgrant0607 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zparnold commented Feb 13, 2019

liggitt commented Feb 13, 2019

liggitt commented Feb 13, 2019 • edited

Rajakavitha1 commented Feb 17, 2019

zparnold commented Feb 17, 2019

k8s-ci-robot commented Feb 17, 2019

k8sio-netlify-preview-bot commented Jan 9, 2019 •

edited by netlify bot

liggitt commented Feb 13, 2019 •

edited