add ProcMount option #1934

jessfraz · 2018-03-15T21:07:54Z

/cc sig-node-proposals

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

jessfraz · 2018-03-15T21:13:35Z

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

jessfraz · 2018-03-15T21:17:11Z

cc @rhatdan

feiskyer · 2018-03-16T03:55:47Z

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

k8s-ci-robot · 2018-03-16T03:55:51Z

@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?

tallclair · 2018-03-16T20:38:15Z

contributors/design-proposals/node/cri-rawproc.md

+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.


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

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

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.

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.

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.

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?

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.

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 · 2018-03-17T00:47:39Z

/cc @Random-Liu @mrunalp

jessfraz · 2018-03-20T18:18:37Z

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

Random-Liu · 2018-03-20T20:16:29Z

contributors/design-proposals/node/cri-rawproc.md

+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.
+


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.

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.

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.

yujuhong · 2018-03-20T20:19:39Z

contributors/design-proposals/node/cri-rawproc.md

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


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.

@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.

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.

@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 is why I need it https://blog.jessfraz.com/post/building-container-images-securely-on-kubernetes/

Random-Liu · 2018-03-20T20:22:13Z

contributors/design-proposals/node/cri-rawproc.md

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


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.

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

AkihiroSuda · 2018-03-21T03:30:56Z

contributors/design-proposals/node/cri-rawproc.md

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


repeated string raw_access instead of bool?

thats sounds right :)

jessfraz · 2018-03-21T13:15:45Z

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 · 2018-03-22T17:53:39Z

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

dchen1107 · 2018-03-22T18:09:39Z

/assign @liggitt

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

stmcginnis · 2018-03-22T18:33:13Z

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

jessfraz · 2018-05-17T22:45:08Z

@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 · 2018-05-17T23:18:25Z

am i the first in this chicken and egg problem lol

Random-Liu · 2018-05-23T00:29:28Z

@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 · 2018-05-23T00:31:25Z

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 · 2018-05-24T18:52:39Z

opened kubernetes/kubernetes#64283

@Random-Liu

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

@Random-Liu

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

@Random-Liu

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

@Random-Liu

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

@Random-Liu

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

@Random-Liu

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

@Random-Liu

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

@Random-Liu

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

@Random-Liu

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

@Random-Liu

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

@Random-Liu

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

@Random-Liu

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

@Random-Liu

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

@Random-Liu

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

mariusgrigoriu · 2018-11-26T19:26:02Z

What is the security tradeoff a cluster operator is making by allowing unmasked ProcMounts in their pod security policies?

dimm0 · 2020-05-08T00:34:51Z

What is the security tradeoff a cluster operator is making by allowing unmasked ProcMounts in their pod security policies?

Could somebody answer this plz?

ThisGuyCodes · 2020-05-15T03:02:28Z

@dimm0 does this help? #1934 (comment)

dimm0 · 2020-05-15T03:10:51Z

Yup, thanks

add ProcMount option

k8s-ci-robot added size/M Denotes a PR that changes 30-99 lines, ignoring generated files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. labels Mar 15, 2018

k8s-github-robot added kind/design Categorizes issue or PR as related to design. sig/node Categorizes an issue or PR as relevant to SIG Node. labels Mar 15, 2018

k8s-ci-robot requested review from yujuhong, feiskyer, tallclair and dchen1107 March 16, 2018 03:55

tallclair reviewed Mar 16, 2018

View reviewed changes

k8s-ci-robot requested review from mrunalp and Random-Liu March 17, 2018 00:47

jessfraz force-pushed the rawproc branch from 905bf89 to d397a00 Compare March 20, 2018 18:18

Random-Liu reviewed Mar 20, 2018

View reviewed changes

yujuhong reviewed Mar 20, 2018

View reviewed changes

Random-Liu reviewed Mar 20, 2018

View reviewed changes

AkihiroSuda reviewed Mar 21, 2018

View reviewed changes

jessfraz force-pushed the rawproc branch from d397a00 to 3715ddd Compare March 22, 2018 17:53

k8s-github-robot added the sig/auth Categorizes an issue or PR as relevant to SIG Auth. label Mar 22, 2018

dchen1107 self-assigned this Mar 22, 2018

k8s-ci-robot assigned liggitt Mar 22, 2018

jessfraz deleted the rawproc branch May 17, 2018 22:29

jessfraz mentioned this pull request May 24, 2018

Add a ProcMount option to the SecurityContext & AllowedProcMountTypes to PodSecurityPolicy kubernetes/kubernetes#64283

Merged

cstrahan mentioned this pull request Mar 21, 2019

Option to make sandbox work in Docker with its default seccomp filter NixOS/nix#2719

Closed

MadhavJivrajani pushed a commit to MadhavJivrajani/community that referenced this pull request Nov 30, 2021

Merge pull request kubernetes#1934 from jessfraz/rawproc

22a160f

add ProcMount option

This was referenced Oct 2, 2023

add ProcMount option kubernetes/enhancements#4265

Open

Add restrospetive KEP for ProcMount and target at Beta kubernetes/enhancements#4266

Merged

KEP 4265: address follow up comments kubernetes/enhancements#4279

Closed


		It will be false by default.

		This will also add a `AllowRawProc` to the `PodSecurityPolicy` to allow

add ProcMount option #1934

add ProcMount option #1934

Conversation

jessfraz commented Mar 15, 2018

jessfraz commented Mar 15, 2018

jessfraz commented Mar 15, 2018

feiskyer commented Mar 16, 2018

k8s-ci-robot commented Mar 16, 2018

tallclair 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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

yujuhong commented Mar 17, 2018

jessfraz commented Mar 20, 2018

Random-Liu Mar 20, 2018 • edited Loading

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

Choose a reason for hiding this comment

Random-Liu Mar 20, 2018 • edited Loading

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

jessfraz commented Mar 21, 2018

jessfraz commented Mar 22, 2018

dchen1107 commented Mar 22, 2018

stmcginnis commented Mar 22, 2018

jessfraz commented May 17, 2018

jessfraz commented May 17, 2018

Random-Liu commented May 23, 2018 • edited Loading

jessfraz commented May 23, 2018 • edited Loading

jessfraz commented May 24, 2018

mariusgrigoriu commented Nov 26, 2018

dimm0 commented May 8, 2020

ThisGuyCodes commented May 15, 2020

dimm0 commented May 15, 2020

Random-Liu Mar 20, 2018 •

edited

Loading

Random-Liu Mar 20, 2018 •

edited

Loading

Random-Liu commented May 23, 2018 •

edited

Loading

jessfraz commented May 23, 2018 •

edited

Loading