New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add ProcMount option #1934

Merged
merged 1 commit into from May 17, 2018

Conversation

@jessfraz
Contributor

jessfraz commented Mar 15, 2018

/cc sig-node-proposals

see also:
moby/moby#36597
opencontainers/runc#1658 (comment)

@jessfraz

This comment has been minimized.

Contributor

jessfraz commented Mar 15, 2018

cc @tallclair @dchen1107 happy to discuss at next sig-node meeting

@jessfraz

This comment has been minimized.

Contributor

jessfraz commented Mar 15, 2018

@feiskyer

This comment has been minimized.

Member

feiskyer commented Mar 16, 2018

@k8s-ci-robot

This comment has been minimized.

Contributor

k8s-ci-robot commented Mar 16, 2018

@feiskyer: GitHub didn't allow me to request PR reviews from the following users: rhatdan.

Note that only kubernetes members and repo collaborators can review this PR, and authors cannot review their own PRs.

In response to this:

/cc @tallclair @dchen1107 @rhatdan @yujuhong @feiskyer

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@tallclair

I'm definitely in favor of more fine-grained controls than privileged. How is this handled by non-docker runtimes?

Currently the way docker and most other container runtimes work is by masking
and setting as read-only certain paths in `/proc`. This is to prevent data
from being exposed into a container that should not be. However, there are
certain use-cases where it is necessary to turn this off.

This comment has been minimized.

@tallclair

tallclair Mar 16, 2018

Member

Are there any other constraints that are lifted by running privileged? Device hiding?

This comment has been minimized.

@jessfraz

jessfraz Mar 16, 2018

Contributor

Privileged add all caps and all host devices. So this won’t do either of those :)

This comment has been minimized.

@rhatdan

rhatdan Mar 17, 2018

Yup --privileged turns off seccomp, adds all caps, turns off SELinux and AppArmor, adds all devices from most, turns off the device cgroup, this allows processes inside of the container to make and interact with any devices. Exposes read/write kernel file systems.

This comment has been minimized.

@rhatdan

rhatdan Mar 17, 2018

You might want to add something equivalent to --device all where the Container Runtime would expose all devices from the host to the container and turn off device cgroup. As a separate knob. Not sure how many people other then people debugging would ever turn these knobs.

This comment has been minimized.

@rhatdan

rhatdan Mar 17, 2018

CRI-O Does whatever Kubernetes tells it to do, If K8s supports rawproc/CRI-O will support Rawproc.
podman currently does everything that docker does.
Know idea what kind of controls RKT has.
LXC can probably do anything, since it has knobs for everything.

This comment has been minimized.

@tallclair

tallclair Mar 20, 2018

Member

You might want to add something equivalent to --device all where the Container Runtime would expose all devices from the host to the container and turn off device cgroup.

Yeah, that's what I was getting at. We already expose options for capabiltiise, seccomp, and AppArmor. I think we're missing a knob to bipass SELinux (or whatever the privileged behavior is there), disable the device cgroup, and rawproc. Is there anything else?

This comment has been minimized.

@smarterclayton

smarterclayton Mar 22, 2018

Contributor

Which users would I definitely not give rawProc to? Might be good to link/include a capsule "here's why /proc/sys being writable is / is-not dangerous" description here.

@rhatdan I know this was because we wanted to close off the option, if selinux is enough to protect those subsequently I'm less worried.

I want to run unprivileged nested containers if we have sufficient defense behind /proc now.

This comment has been minimized.

@jessfraz

jessfraz Mar 22, 2018

Contributor

Which users would I definitely not give rawProc to?

Someone evil? Who would possibly try to exploit the info in proc with an 0day. Remember the user inside is still unprivileged so doing things to proc would be off limits regardless. So we could make it so rawProc is only allowed if the user !=0 :)

@yujuhong

This comment has been minimized.

Contributor

yujuhong commented Mar 17, 2018

@k8s-ci-robot k8s-ci-robot requested review from mrunalp and Random-Liu Mar 17, 2018

@jessfraz

This comment has been minimized.

Contributor

jessfraz commented Mar 20, 2018

Added a bit more information on usecases hopefully that is useful.

and setting as read-only certain paths in `/proc`. This is to prevent data
from being exposed into a container that should not be. However, there are
certain use-cases where it is necessary to turn this off.

This comment has been minimized.

@Random-Liu

Random-Liu Mar 20, 2018

Member

Instead of adding a rawproc option at CRI level, why don't we just expose maskedPaths and readonlyPaths (link) in CRI?

I'm not saying that we should do that, but I want to make sure we've considered that option.

I think it is more generic. If needed, we can leverage that to mask/unmask or set read-only
for other paths in the future, instead of adding another rawXXX, e.g. rawsys.

This comment has been minimized.

@mrunalp

mrunalp Mar 20, 2018

I agree with @Random-Liu. We could just expose maskedPaths and readonlyPaths.
A higher level abstraction makes more sense when it isn't portable between runtimes.

This comment has been minimized.

@jessfraz

jessfraz Mar 20, 2018

Contributor

ok thats for cri, but what do you want for the top level, the same? I will do whatever everyone wants, I really have no fight in the naming, I just need a way to do this.

It will be false by default.
This will also add a `AllowRawProc` to the `PodSecurityPolicy` to allow

This comment has been minimized.

@yujuhong

yujuhong Mar 20, 2018

Contributor

My $.02: The proposal should be about adding a feature in kubernetes, and have sections on kubernetes API, and CRI changes, respectively. The title and the way that the content is arranged seem to suggest that this is only a CRI change.

This comment has been minimized.

@derekwaynecarr

derekwaynecarr Mar 20, 2018

Member

@yujuhong i had missed this section in sig-node today, agree it would be good to start from the user facing API down to the CRI.

This comment has been minimized.

@jessfraz

jessfraz Mar 20, 2018

Contributor

I really don't mind what the CRI api is, i really just need this in the top level, what do you suggest then? making this proposal just for the top level, you all can implement in cri like i did in docker...
moby/moby#36644

I really don't even care about the name, lol, I just need a way to do it.

This comment has been minimized.

@yujuhong

yujuhong Mar 21, 2018

Contributor

@jessfraz CRI is only a small part of this proposal. The more important questions are why Kubernetes needs this, what the use cases are, and how this would be represented in the Kubernetes API. We can discuss how to add this option to CRI after those are nailed down.

I am unclear about the use cases. Could you explain why nested containers are needed or point us to related issues and proposals? As for adding this to PodSecurityPolicy, I think there are more people with opinions on that (hence my suggestion on changing the proposal to get reviews from the right folks).

If I'm wrong and this is a pure CRI change to support finer-grained control (e.g., break down of Privileged), let me know and we can review as it is.

This comment has been minimized.

It will be false by default.
This will also add a `AllowRawProc` to the `PodSecurityPolicy` to allow

This comment has been minimized.

@Random-Liu

Random-Liu Mar 20, 2018

Member

Similar questions with https://github.com/kubernetes/community/pull/1934/files#r175907931.

At Kubernetes API level, should we expose highest level abstraction privileged? Or several lower level abstractions rawproc, rawsys, rawXXX? Or expose maskedPaths and readonlyPaths directly?

None of them seems ideal to me.

This comment has been minimized.

@jessfraz

jessfraz Mar 20, 2018

Contributor

I think it is confusing for users at the top level to have the options of configuring everything but up to you all.

This proposal suggests adding the following to `bool` `LinuxSandboxSecurityContext`:
```
bool raw_proc

This comment has been minimized.

@AkihiroSuda

AkihiroSuda Mar 21, 2018

repeated string raw_access instead of bool?

This comment has been minimized.

@jessfraz

jessfraz Mar 21, 2018

Contributor

thats sounds right :)

@jessfraz

This comment has been minimized.

Contributor

jessfraz commented Mar 21, 2018

I am going to redo this as a proposal for the high level k8s api, and you all can figure out naming for cri however you want, how does that sound?

@jessfraz

This comment has been minimized.

Contributor

jessfraz commented Mar 22, 2018

Updated to be a proposal for the top level api, CRI can do as it pleases :)

@dchen1107 dchen1107 self-assigned this Mar 22, 2018

@dchen1107

This comment has been minimized.

Member

dchen1107 commented Mar 22, 2018

/assign @liggitt

Looks good to me on node side. Assign to @liggitt for the top level API approval.

@stmcginnis

This comment has been minimized.

stmcginnis commented Mar 22, 2018

The title probably should be updated now to avoid any confusion.

@jessfraz jessfraz changed the title from cri: add rawproc option to add rawproc option Mar 22, 2018

@liggitt liggitt referenced this pull request Mar 22, 2018

Closed

[PodSecurityPolicy] API changes #56174

0 of 3 tasks complete
@jessfraz

This comment has been minimized.

Contributor

jessfraz commented May 17, 2018

updated :) thanks @smarterclayton that definitely looks more intuituve

add ProcMount option
Signed-off-by: Jess Frazelle <acidburn@microsoft.com>
@smarterclayton

This comment has been minimized.

Contributor

smarterclayton commented May 17, 2018

/lgtm
/approve

Thanks for the patience

@k8s-ci-robot

This comment has been minimized.

Contributor

k8s-ci-robot commented May 17, 2018

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: smarterclayton

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:

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 k8s-ci-robot merged commit 09ae39d into kubernetes:master May 17, 2018

3 checks passed

cla/linuxfoundation jessfraz authorized
Details
pull-community-verify Job succeeded.
Details
tide In merge pool.
Details

@jessfraz jessfraz deleted the jessfraz:rawproc branch May 17, 2018

@jessfraz

This comment has been minimized.

Contributor

jessfraz commented May 17, 2018

@Random-Liu @mrunalp how do you want to do this with cri i am happy to open a PR :) or if you all want a certain way that can be as well

@jessfraz

This comment has been minimized.

Contributor

jessfraz commented May 17, 2018

am i the first in this chicken and egg problem lol

@Random-Liu

This comment has been minimized.

Member

Random-Liu commented May 23, 2018

@jessfraz There are 2 options:

  • Option 1: Expose MaskedPath and ReadonlyPaths in CRI, and let kubelet apply the default, and kubelet can then handle ProcMountType correspondingly.
    • Pros: Consistent behavior across different container runtimes.
  • Option 2: Have ProcMountType in CRI, and let container runtimes handle it separately.

Today it is still container runtime handles the default OCI spec, so option 2 seems align more with today's model. But since the default is commonly agreed on, I do hope we can move the behavior up to kubelet gradually (option 1), instead of having a duplicated implementation in each container runtime, so I personally prefer option 1.

Another question is how do we support this in dockershim? I'm fine with not supporting it, but would like to know whether it is possible. :)

@yujuhong Do you have any preference?

@jessfraz

This comment has been minimized.

Contributor

jessfraz commented May 23, 2018

I have no preference on the first since that is yours all to maintain :) so I am happy to make the PR any way you want , going to do option 1

as far as docker, i made a PR but let's turn off support until that's in and then i can add support after :)

@jessfraz

This comment has been minimized.

Contributor

jessfraz commented May 24, 2018

k8s-merge-robot added a commit to kubernetes/kubernetes that referenced this pull request Aug 31, 2018

Merge pull request #64283 from jessfraz/ProcMountType
Automatic merge from submit-queue (batch tested with PRs 64283, 67910, 67803, 68100). If you want to cherry-pick this change to another branch, please follow the instructions here: https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md.

Add a ProcMount option to the SecurityContext & AllowedProcMountTypes to PodSecurityPolicy

So there is a bit of a chicken and egg problem here in that the CRI runtimes will need to implement this for there to be any sort of e2e testing.

**What this PR does / why we need it**: This PR implements design proposal kubernetes/community#1934. This adds a ProcMount option to the SecurityContext and AllowedProcMountTypes to PodSecurityPolicy

Relies on google/cadvisor#1967

**Release note**:

```release-note
ProcMount added to SecurityContext and AllowedProcMounts added to PodSecurityPolicy to allow paths in the container's /proc to not be masked.
```

cc @Random-Liu @mrunalp

k8s-publishing-bot added a commit to kubernetes/api that referenced this pull request Sep 1, 2018

Merge pull request #64283 from jessfraz/ProcMountType
Automatic merge from submit-queue (batch tested with PRs 64283, 67910, 67803, 68100). If you want to cherry-pick this change to another branch, please follow the instructions here: https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md.

Add a ProcMount option to the SecurityContext & AllowedProcMountTypes to PodSecurityPolicy

So there is a bit of a chicken and egg problem here in that the CRI runtimes will need to implement this for there to be any sort of e2e testing.

**What this PR does / why we need it**: This PR implements design proposal kubernetes/community#1934. This adds a ProcMount option to the SecurityContext and AllowedProcMountTypes to PodSecurityPolicy

Relies on google/cadvisor#1967

**Release note**:

```release-note
ProcMount added to SecurityContext and AllowedProcMounts added to PodSecurityPolicy to allow paths in the container's /proc to not be masked.
```

cc @Random-Liu @mrunalp

Kubernetes-commit: 39004e852bb523d0497343705ee2bf42b4e9c3e3

k8s-publishing-bot added a commit to kubernetes/apiserver that referenced this pull request Sep 1, 2018

Merge pull request #64283 from jessfraz/ProcMountType
Automatic merge from submit-queue (batch tested with PRs 64283, 67910, 67803, 68100). If you want to cherry-pick this change to another branch, please follow the instructions here: https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md.

Add a ProcMount option to the SecurityContext & AllowedProcMountTypes to PodSecurityPolicy

So there is a bit of a chicken and egg problem here in that the CRI runtimes will need to implement this for there to be any sort of e2e testing.

**What this PR does / why we need it**: This PR implements design proposal kubernetes/community#1934. This adds a ProcMount option to the SecurityContext and AllowedProcMountTypes to PodSecurityPolicy

Relies on google/cadvisor#1967

**Release note**:

```release-note
ProcMount added to SecurityContext and AllowedProcMounts added to PodSecurityPolicy to allow paths in the container's /proc to not be masked.
```

cc @Random-Liu @mrunalp

Kubernetes-commit: 39004e852bb523d0497343705ee2bf42b4e9c3e3

k8s-publishing-bot added a commit to kubernetes/kube-aggregator that referenced this pull request Sep 1, 2018

Merge pull request #64283 from jessfraz/ProcMountType
Automatic merge from submit-queue (batch tested with PRs 64283, 67910, 67803, 68100). If you want to cherry-pick this change to another branch, please follow the instructions here: https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md.

Add a ProcMount option to the SecurityContext & AllowedProcMountTypes to PodSecurityPolicy

So there is a bit of a chicken and egg problem here in that the CRI runtimes will need to implement this for there to be any sort of e2e testing.

**What this PR does / why we need it**: This PR implements design proposal kubernetes/community#1934. This adds a ProcMount option to the SecurityContext and AllowedProcMountTypes to PodSecurityPolicy

Relies on google/cadvisor#1967

**Release note**:

```release-note
ProcMount added to SecurityContext and AllowedProcMounts added to PodSecurityPolicy to allow paths in the container's /proc to not be masked.
```

cc @Random-Liu @mrunalp

Kubernetes-commit: 39004e852bb523d0497343705ee2bf42b4e9c3e3

k8s-publishing-bot added a commit to kubernetes/sample-apiserver that referenced this pull request Sep 1, 2018

Merge pull request #64283 from jessfraz/ProcMountType
Automatic merge from submit-queue (batch tested with PRs 64283, 67910, 67803, 68100). If you want to cherry-pick this change to another branch, please follow the instructions here: https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md.

Add a ProcMount option to the SecurityContext & AllowedProcMountTypes to PodSecurityPolicy

So there is a bit of a chicken and egg problem here in that the CRI runtimes will need to implement this for there to be any sort of e2e testing.

**What this PR does / why we need it**: This PR implements design proposal kubernetes/community#1934. This adds a ProcMount option to the SecurityContext and AllowedProcMountTypes to PodSecurityPolicy

Relies on google/cadvisor#1967

**Release note**:

```release-note
ProcMount added to SecurityContext and AllowedProcMounts added to PodSecurityPolicy to allow paths in the container's /proc to not be masked.
```

cc @Random-Liu @mrunalp

Kubernetes-commit: 39004e852bb523d0497343705ee2bf42b4e9c3e3

k8s-publishing-bot added a commit to kubernetes/apiextensions-apiserver that referenced this pull request Sep 1, 2018

Merge pull request #64283 from jessfraz/ProcMountType
Automatic merge from submit-queue (batch tested with PRs 64283, 67910, 67803, 68100). If you want to cherry-pick this change to another branch, please follow the instructions here: https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md.

Add a ProcMount option to the SecurityContext & AllowedProcMountTypes to PodSecurityPolicy

So there is a bit of a chicken and egg problem here in that the CRI runtimes will need to implement this for there to be any sort of e2e testing.

**What this PR does / why we need it**: This PR implements design proposal kubernetes/community#1934. This adds a ProcMount option to the SecurityContext and AllowedProcMountTypes to PodSecurityPolicy

Relies on google/cadvisor#1967

**Release note**:

```release-note
ProcMount added to SecurityContext and AllowedProcMounts added to PodSecurityPolicy to allow paths in the container's /proc to not be masked.
```

cc @Random-Liu @mrunalp

Kubernetes-commit: 39004e852bb523d0497343705ee2bf42b4e9c3e3

sttts pushed a commit to sttts/apiserver that referenced this pull request Sep 5, 2018

Merge pull request #64283 from jessfraz/ProcMountType
Automatic merge from submit-queue (batch tested with PRs 64283, 67910, 67803, 68100). If you want to cherry-pick this change to another branch, please follow the instructions here: https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md.

Add a ProcMount option to the SecurityContext & AllowedProcMountTypes to PodSecurityPolicy

So there is a bit of a chicken and egg problem here in that the CRI runtimes will need to implement this for there to be any sort of e2e testing.

**What this PR does / why we need it**: This PR implements design proposal kubernetes/community#1934. This adds a ProcMount option to the SecurityContext and AllowedProcMountTypes to PodSecurityPolicy

Relies on google/cadvisor#1967

**Release note**:

```release-note
ProcMount added to SecurityContext and AllowedProcMounts added to PodSecurityPolicy to allow paths in the container's /proc to not be masked.
```

cc @Random-Liu @mrunalp

Kubernetes-commit: 39004e852bb523d0497343705ee2bf42b4e9c3e3

sttts pushed a commit to sttts/kube-aggregator that referenced this pull request Sep 5, 2018

Merge pull request #64283 from jessfraz/ProcMountType
Automatic merge from submit-queue (batch tested with PRs 64283, 67910, 67803, 68100). If you want to cherry-pick this change to another branch, please follow the instructions here: https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md.

Add a ProcMount option to the SecurityContext & AllowedProcMountTypes to PodSecurityPolicy

So there is a bit of a chicken and egg problem here in that the CRI runtimes will need to implement this for there to be any sort of e2e testing.

**What this PR does / why we need it**: This PR implements design proposal kubernetes/community#1934. This adds a ProcMount option to the SecurityContext and AllowedProcMountTypes to PodSecurityPolicy

Relies on google/cadvisor#1967

**Release note**:

```release-note
ProcMount added to SecurityContext and AllowedProcMounts added to PodSecurityPolicy to allow paths in the container's /proc to not be masked.
```

cc @Random-Liu @mrunalp

Kubernetes-commit: 39004e852bb523d0497343705ee2bf42b4e9c3e3

sttts pushed a commit to sttts/sample-apiserver that referenced this pull request Sep 5, 2018

Merge pull request #64283 from jessfraz/ProcMountType
Automatic merge from submit-queue (batch tested with PRs 64283, 67910, 67803, 68100). If you want to cherry-pick this change to another branch, please follow the instructions here: https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md.

Add a ProcMount option to the SecurityContext & AllowedProcMountTypes to PodSecurityPolicy

So there is a bit of a chicken and egg problem here in that the CRI runtimes will need to implement this for there to be any sort of e2e testing.

**What this PR does / why we need it**: This PR implements design proposal kubernetes/community#1934. This adds a ProcMount option to the SecurityContext and AllowedProcMountTypes to PodSecurityPolicy

Relies on google/cadvisor#1967

**Release note**:

```release-note
ProcMount added to SecurityContext and AllowedProcMounts added to PodSecurityPolicy to allow paths in the container's /proc to not be masked.
```

cc @Random-Liu @mrunalp

Kubernetes-commit: 39004e852bb523d0497343705ee2bf42b4e9c3e3

sttts pushed a commit to sttts/apiextensions-apiserver that referenced this pull request Sep 5, 2018

Merge pull request #64283 from jessfraz/ProcMountType
Automatic merge from submit-queue (batch tested with PRs 64283, 67910, 67803, 68100). If you want to cherry-pick this change to another branch, please follow the instructions here: https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md.

Add a ProcMount option to the SecurityContext & AllowedProcMountTypes to PodSecurityPolicy

So there is a bit of a chicken and egg problem here in that the CRI runtimes will need to implement this for there to be any sort of e2e testing.

**What this PR does / why we need it**: This PR implements design proposal kubernetes/community#1934. This adds a ProcMount option to the SecurityContext and AllowedProcMountTypes to PodSecurityPolicy

Relies on google/cadvisor#1967

**Release note**:

```release-note
ProcMount added to SecurityContext and AllowedProcMounts added to PodSecurityPolicy to allow paths in the container's /proc to not be masked.
```

cc @Random-Liu @mrunalp

Kubernetes-commit: 39004e852bb523d0497343705ee2bf42b4e9c3e3

k8s-publishing-bot added a commit to kubernetes/apiserver that referenced this pull request Sep 6, 2018

Merge pull request #64283 from jessfraz/ProcMountType
Automatic merge from submit-queue (batch tested with PRs 64283, 67910, 67803, 68100). If you want to cherry-pick this change to another branch, please follow the instructions here: https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md.

Add a ProcMount option to the SecurityContext & AllowedProcMountTypes to PodSecurityPolicy

So there is a bit of a chicken and egg problem here in that the CRI runtimes will need to implement this for there to be any sort of e2e testing.

**What this PR does / why we need it**: This PR implements design proposal kubernetes/community#1934. This adds a ProcMount option to the SecurityContext and AllowedProcMountTypes to PodSecurityPolicy

Relies on google/cadvisor#1967

**Release note**:

```release-note
ProcMount added to SecurityContext and AllowedProcMounts added to PodSecurityPolicy to allow paths in the container's /proc to not be masked.
```

cc @Random-Liu @mrunalp

Kubernetes-commit: 39004e852bb523d0497343705ee2bf42b4e9c3e3

k8s-publishing-bot added a commit to kubernetes/kube-aggregator that referenced this pull request Sep 6, 2018

Merge pull request #64283 from jessfraz/ProcMountType
Automatic merge from submit-queue (batch tested with PRs 64283, 67910, 67803, 68100). If you want to cherry-pick this change to another branch, please follow the instructions here: https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md.

Add a ProcMount option to the SecurityContext & AllowedProcMountTypes to PodSecurityPolicy

So there is a bit of a chicken and egg problem here in that the CRI runtimes will need to implement this for there to be any sort of e2e testing.

**What this PR does / why we need it**: This PR implements design proposal kubernetes/community#1934. This adds a ProcMount option to the SecurityContext and AllowedProcMountTypes to PodSecurityPolicy

Relies on google/cadvisor#1967

**Release note**:

```release-note
ProcMount added to SecurityContext and AllowedProcMounts added to PodSecurityPolicy to allow paths in the container's /proc to not be masked.
```

cc @Random-Liu @mrunalp

Kubernetes-commit: 39004e852bb523d0497343705ee2bf42b4e9c3e3

k8s-publishing-bot added a commit to kubernetes/sample-apiserver that referenced this pull request Sep 6, 2018

Merge pull request #64283 from jessfraz/ProcMountType
Automatic merge from submit-queue (batch tested with PRs 64283, 67910, 67803, 68100). If you want to cherry-pick this change to another branch, please follow the instructions here: https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md.

Add a ProcMount option to the SecurityContext & AllowedProcMountTypes to PodSecurityPolicy

So there is a bit of a chicken and egg problem here in that the CRI runtimes will need to implement this for there to be any sort of e2e testing.

**What this PR does / why we need it**: This PR implements design proposal kubernetes/community#1934. This adds a ProcMount option to the SecurityContext and AllowedProcMountTypes to PodSecurityPolicy

Relies on google/cadvisor#1967

**Release note**:

```release-note
ProcMount added to SecurityContext and AllowedProcMounts added to PodSecurityPolicy to allow paths in the container's /proc to not be masked.
```

cc @Random-Liu @mrunalp

Kubernetes-commit: 39004e852bb523d0497343705ee2bf42b4e9c3e3

k8s-publishing-bot added a commit to kubernetes/apiextensions-apiserver that referenced this pull request Sep 6, 2018

Merge pull request #64283 from jessfraz/ProcMountType
Automatic merge from submit-queue (batch tested with PRs 64283, 67910, 67803, 68100). If you want to cherry-pick this change to another branch, please follow the instructions here: https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md.

Add a ProcMount option to the SecurityContext & AllowedProcMountTypes to PodSecurityPolicy

So there is a bit of a chicken and egg problem here in that the CRI runtimes will need to implement this for there to be any sort of e2e testing.

**What this PR does / why we need it**: This PR implements design proposal kubernetes/community#1934. This adds a ProcMount option to the SecurityContext and AllowedProcMountTypes to PodSecurityPolicy

Relies on google/cadvisor#1967

**Release note**:

```release-note
ProcMount added to SecurityContext and AllowedProcMounts added to PodSecurityPolicy to allow paths in the container's /proc to not be masked.
```

cc @Random-Liu @mrunalp

Kubernetes-commit: 39004e852bb523d0497343705ee2bf42b4e9c3e3
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment