Skip to content
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

KEP: security conformance proposal #2081

Closed
wants to merge 1 commit into
base: master
from

Conversation

@easeway
Copy link

easeway commented Apr 26, 2018

Summary

Security Conformance defines citeria to certify a Kubernetes cluster to be minimally secure.

Motivation

Configuring a Kubernetes cluster is complicated,
and it's very easy to mis-configure a cluster to be insecure.
The current Kubernetes conformance test suite barely covers security aspects.

/sig auth
/sig testing
/assign @tallclair

@davidopp @tallclair @ericchiang @liggitt @bgrant0607

@k8s-ci-robot

This comment has been minimized.

Copy link
Contributor

k8s-ci-robot commented Apr 26, 2018

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: idvoretskyi

Assign the PR to them by writing /assign @idvoretskyi in a comment when ready.

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 requested review from idvoretskyi and jbeda Apr 26, 2018

@easeway easeway force-pushed the easeway:kep-security-conformance branch from 4c4360c to 5b9afb6 Apr 26, 2018

@easeway

This comment has been minimized.

Copy link
Author

easeway commented Apr 26, 2018

@easeway easeway force-pushed the easeway:kep-security-conformance branch 2 times, most recently from a556220 to 1b028ca Apr 26, 2018

- "@easeway"
owning-sig: sig-auth
participating-sigs:
- sig-testing

This comment has been minimized.

@liggitt

liggitt Apr 27, 2018

Member

would like to see the sigs that design/maintain the components under test here as well: apiserver (sig-api-machinery), kubelet (sig-node), ingress (sig-network), and cluster setup (sig-cluster-lifecycle)... this is a cross-cutting aspect and requires cross-sig involvement to be successful

This comment has been minimized.

@easeway

easeway Apr 27, 2018

Author

Yes, I will add related sigs.


## Proposal

### Conformance Profiles

This comment has been minimized.

@liggitt

liggitt Apr 27, 2018

Member

I know the idea of conformance profiles has been discussed, but is this defining it for the first time? Should that concept get hoisted out and agreed on separately, independent of wanting to use "profiles" for a particular functional area? Example questions:

  • how do we expect conformance profiles in different functional areas to work? (security profiles: essential, restricted, isolated; storage profiles: nfs, gluster, ...; rbac profile; etc)
  • the combinatorial possibilities are endless; do we expect distributions to submit results for various configurations and the profiles that pass on those configurations?
  • most of the controls required to pass the restricted/isolated profiles would prevent many of the existing normal conformance tests from running successfully. how do you plan to structure the tests to allow some conformance tests access to privileged pods, hostPath volume mounts, etc, while still running the security tests in restricted namespaces representative of default permissions/policy?

cc @kubernetes/sig-architecture-proposals

This comment has been minimized.

@easeway

easeway Apr 27, 2018

Author

This proposal is security focused. Other profiles are out-of-scope. So "conformance profiles" is not a good name. I feel using "security conformance profiles" will be better. Regarding testing against restricted/isolated profiles, I have some details in the Implementation Details section. I will refine the content according to your question.

focusing on the threaten from outside the cluster (via APIs),
non-privileged (non-root) access on the host running master and kubelet,
not covering the threaten from user workloads (non-critical, non-system Pods) running inside the cluster.
The criteria in this category must always be satisfied;

This comment has been minimized.

@liggitt

liggitt Apr 27, 2018

Member

The criteria in this category must always be satisfied;

does that mean you envision making these part of the existing conformance tests, not an optional profile?

This comment has been minimized.

@easeway

easeway Apr 27, 2018

Author

I will further clarify in the doc. This is an optional profile if security is optional. Otherwise it's mandatory.


*Conformance Profile: Essential*

Anonymous access to Kubernetes API should be denied as unauthorized.

This comment has been minimized.

@liggitt

liggitt Apr 27, 2018

Member

this seems underspecified. to what portion of the API? discovery information? openapi schema docs? or to actual resources? what about intentionally published resources containing trust roots, public keys, etc?

This comment has been minimized.

@easeway

easeway Apr 27, 2018

Author

I think denying anonymous access is unreasonable. I will remove this. Because at least for healthz checks, it should allow anonymous access, from external monitoring systems. For discovery, swagger/openapi, it's OK to allow anonymous access. For the rest of APIs, as long as authorizers will block "system:unauthorized", it won't be a security concern.


*Conformance Profile: Essential*

Accessing Kubernetes API using default service accounts from any namespace should be rejected as forbidden.

This comment has been minimized.

@liggitt

liggitt Apr 27, 2018

Member

Accessing Kubernetes API using default service accounts from any namespace should be rejected as forbidden.

The above questions apply as well (which parts of the API? discovery information? openapi schema docs? or to actual resources?)

Also, did you mean "the service account named default in every namespace should be forbidden" or "by default, a service account in any namespace should be forbidden"? The former doesn't seem reasonable (why shouldn't a cluster be allowed to set up a privileged namespace, and give permissions to the default service account in that namespace). The latter seems better ("deny by default"), and could be tested by giving the test a representative namespace to exercise.

This comment has been minimized.

@easeway

easeway Apr 27, 2018

Author

I will rephrase this. The idea behind that is the service account named default should have minimum privilege. I will spec the minimum privilege for discussion.

however the orchestration part (test setup) will be separate.

- API validation
Similar to existing test cases, directly calling Kubernetes APIs. Certain API validations are performed by running a Pod inside a namespace, with default service account.

This comment has been minimized.

@liggitt

liggitt Apr 27, 2018

Member

"a representative namespace and service account" vs literally the service account named "default"?

This comment has been minimized.

@easeway

easeway Apr 27, 2018

Author

The service account named default. I will clarify this.


- non-root user should not be able to access etcd data directory
- non-root user should not be able to access any kubeconfig files
- non-root user should not be able to access any private key files

This comment has been minimized.

@liggitt

liggitt Apr 27, 2018

Member

be careful not to overspecify this... for example, the apiserver, etcd, and controller-manager could be set up to run as non-root users, and their private data would need to be readable only to their user. the important thing is that the private data be readable only to the user running the process intended to be accessing it

This comment has been minimized.

@easeway

easeway Apr 27, 2018

Author

Good point. I will update.


*Conformance Profile: Essential*

The configuration files for API server, controller manager, scheduler and kubelet should have the correct setup of ownership and file permissions.

This comment has been minimized.

@liggitt

liggitt Apr 27, 2018

Member

while I agree it's important to set these things up correctly, this seems like quite a departure from the types of checks done by the existing conformance tests. how do you plan to account for different config paths, configurations, and setups of various distributions? testing the behavior of the kubernetes API is one thing. testing config/process setup is quite another

This comment has been minimized.

@ericchiang

ericchiang Apr 27, 2018

Member

...or self-hosted setups where the control plane configuration is in the Kubernetes API itself

This comment has been minimized.

@easeway

easeway Apr 27, 2018

Author

Yes. I will put more details.

This comment has been minimized.

@davidopp

davidopp May 5, 2018

Member

I see you addressed that in the "Test file permissions and Command line flags" section later, but I would suggest moving that section up here, since this is the test that needs it.

BTW that section mentioned command-line flags, but it wasn't clear to me which command-line flags you are checking. I guess you are indirectly checking that RBAC is enabled (vs. legacy auth) but are there command-line flags you intend to check directly (by looking at the flags)?

This comment has been minimized.

@easeway

easeway May 7, 2018

Author

I will move the section up here. The command line flags should be defined in security profiles. Different profiles define the command line flags differently. I will list them explicitly here according to Essential, Restricted and Isolated.

This comment has been minimized.

@tallclair

tallclair May 23, 2018

Member

I'm still not convinced that this section is going to be useful as a conformance test. I think this should be discussed with @kubernetes/sig-cluster-lifecycle-pr-reviews - as @liggitt mentioned we haven't tested detailed configuration like this in the past.

*Conformance Profile: Isolated*

Ingress/Egress are blocked for all traffic by default in namespaces.

This comment has been minimized.

@liggitt

liggitt Apr 27, 2018

Member

for the restricted profiles, I expected to see restriction of volume types to limit access to read/modify the node filesystem (e.g. only configmap/secret/emptydir/downwardAPI/projected/pvc volume sources). otherwise, API and host limitations aren't particularly meaningful (if you can just mount and read the directory containing kubelet API credentials, or modify node config files at will)

This comment has been minimized.

@easeway

easeway Apr 27, 2018

Author

Good point. I will add these in.


The following addons should be disabled:

- dashboard

This comment has been minimized.

@liggitt

liggitt Apr 27, 2018

Member

can we be more specific about what is not allowed, and why?

you can configure the dashboard to grant minimal API permissions to the dashboard itself and instead make use of the logged in user's API credentials for API calls (that is the default configuration of the add-on currently). that doesn't seem egregious to me.

on the other hand, the "grant broad permissions to the dashboard and let anyone with network visibility to it use those permissions" configuration should be disabled.

I'm not sure how to generalize that guidance in a testable way. There are other components with similarly broad configuration options (for example, tiller can be deployed to require mTLS authentication, or to require no authentication at all).

This comment has been minimized.

@easeway

easeway Apr 27, 2018

Author

I'm still uncertain if addons should be covered in security conformance, as user may install any addons. Maybe the best way for now is to exclude addons from security conformance.

@ericchiang

This comment has been minimized.

Copy link
Member

ericchiang commented Apr 27, 2018

@easeway easeway force-pushed the easeway:kep-security-conformance branch 2 times, most recently from e998c46 to a66f0c7 Apr 27, 2018

- `Restricted`: in addition to `Essential`,
it covers the threaten from user workloads to the cluster,
not among user workloads (e.g. single-tenancy model);
- `Isolated`: in addition to `Restricted`, it covers the threaten among user workloads (e.g. multi-tenancy model).

This comment has been minimized.

@davidopp

davidopp May 5, 2018

Member

I think there should be at least two flavors of "isolated" -- I hate these words, but something like "soft isolation" and "hard isolation."

This comment has been minimized.

@easeway

easeway May 7, 2018

Author

Could you give a little more details about "soft isolation" and "hard isolation"?

This comment has been minimized.

@easeway

easeway May 7, 2018

Author

according to discussion, the isolation needs to be split into fine grained with different container runtime. E.g. plain container vs HyperVisor based vs gVisor etc.


The behavioral/non-behavioral criteria are categorized into a few security conformance profiles for different levels of security requirements:

- `Essential`: the baseline security requirements for the cluster,

This comment has been minimized.

@davidopp

davidopp May 5, 2018

Member

So the idea is that "essential" means that the cluster is secure when it is not running any applications, and "restricted" means that the cluster is secure when it is running applications? What is the usefulness of making this distinction? Why would someone want "essential" but not "restricted"?

This comment has been minimized.

@easeway

easeway May 7, 2018

Author

The three definitions of Security Conformance Profiles are based on where the threat comes from, and who will be impacted.

Generally, the threat comes from:

  1. Outside of the cluster: the attack surface will be K8S APIs, the hosts including master and nodes.
  2. Inside the cluster: the workload running on K8S cluster

The impact will be on:

  1. The cluster: the cluster may not function or leaking information
  2. The workload: the cluster is still functioning, and secure, while some workload will be compromised, and may compromise other workload

Essential is actually defined for trusted workloads: it focuses on the threat from outside of the cluster and impact on the cluster. It will assume the workload is trusted, and allow privileges on workload. The common use case is a K8S cluster used internally in a team, or an org with all trusted users.

Restricted is based on Essential, and additionally targets the threat from inside. The targeted impact is still on the cluster, not workloads. The common use case will be for untrusted workloads, regardless of tenants. For example, the operators of K8S cluster is responsible for keeping the cluster secure and stable, not considering the influence between workloads.

Isolated based on Restricted, targets threat from both inside and outside, impact on both cluster and workload. It's for multi-tenancy use cases. It will prevent the attack from some tenants' workload to other tenants.

I will give more details on the definitions - mentioning use case categories.


*Conformance Profile: Essential*

The configuration files for API server, controller manager, scheduler and kubelet should have the correct setup of ownership and file permissions.

This comment has been minimized.

@davidopp

davidopp May 5, 2018

Member

I see you addressed that in the "Test file permissions and Command line flags" section later, but I would suggest moving that section up here, since this is the test that needs it.

BTW that section mentioned command-line flags, but it wasn't clear to me which command-line flags you are checking. I guess you are indirectly checking that RBAC is enabled (vs. legacy auth) but are there command-line flags you intend to check directly (by looking at the flags)?


*Conformance Profile: Restricted*

Pod creation with `privileged` set to `true` in `SecurityContext` (Pod or container level)

This comment has been minimized.

@davidopp

davidopp May 5, 2018

Member

Is this true today? You're saying there should be a default PodSecurityPolicy that forbids privileged pods?

This comment has been minimized.

@easeway

easeway May 7, 2018

Author

It's true today, but not because of privileged in SecurityContext. Once PodSecurityPolicy admission control is enabled, no Pod will be created if there's no RBAC rolebinding/clusterrolebinding associated with the Pod service account.

*Conformance Profile: Isolated*

Ingress/Egress are blocked for all traffic for all Pods by default in namespaces,
except `kube-system` and those with special configurations.

This comment has been minimized.

@davidopp

davidopp May 5, 2018

Member

Does this mean kube-system pods do not have any traffic blocked, or that non-kube-system pods are able to talk to kube-system pods, or both?

This comment has been minimized.

@easeway

easeway May 7, 2018

Author

kube-system is not touched, and left as-is. non-kube-system (matching namespace selector) pods, by default, are not allowed to talk to any services in other namespaces, including those in kube-system - not sure if it's too restricted, like shall we open dns to all namespaces, but I think K8S API can be blocked by default - open for discussion.

I will rephrase this to be more clear.

status: provisional
---

# Security Conformance

This comment has been minimized.

@davidopp

davidopp May 5, 2018

Member

I like this proposal, but it seems seems like there are some things missing, for example which admission controllers should be enabled. Basically more of the stuff discuss in
https://docs.google.com/document/d/1jAcsC4sLgEV9__TdgJrMvPa3G73G62tFtMcKQgeIlHM/edit
(though I think you did hit most of the things mentioned in that doc).

BTW I would suggest adding a section discussing the tradeoff between having the test just directly check whether a particular policy is installed, vs. check that the behavior dictated by the policy is actulally enforced. It seems you chose the latter; I think that's fine but it would be good to justify that choice.

This comment has been minimized.

@easeway

easeway May 7, 2018

Author

Yes. I will add a section in alternatives.

@easeway easeway force-pushed the easeway:kep-security-conformance branch from a66f0c7 to 70cab60 May 7, 2018

@k8s-ci-robot k8s-ci-robot added size/XL and removed size/L labels May 7, 2018


### Goals

- A list of behavioral security criteria that can be validated by tests

This comment has been minimized.

@tallclair

tallclair May 9, 2018

Member

language nit: Goals should be actions, e.g. "to provide ..."

### Goals

- A list of behavioral security criteria that can be validated by tests
- A list of non-behavioral security criteria that can be validated by tests

This comment has been minimized.

@tallclair

tallclair May 9, 2018

Member

What is a non-behavioral criteria? Are these getting at implementation specific & implementation independent tests?


### Non-Goals

- Mechanisms to satisfy security criteria

This comment has been minimized.

@tallclair

tallclair May 9, 2018

Member

To test mechanisms or provide mechanisms?

The behavioral/non-behavioral criteria are categorized into a few security conformance profiles for different levels of security requirements:

- `Essential`: (aka `Trusted`) the baseline security requirements for the cluster,
focusing on the threaten from outside the cluster (via APIs) and

This comment has been minimized.

@tallclair

tallclair May 9, 2018

Member

s/threaten/threats/

- etcd data directory is owned and accessible only by the user running etcd;
- kubeconfig files for control plane is owned and accessible only by the user runs the control plane;
- private key files is owned and accessible only by the user who runs the process which consumes the key;
- kubeconfig for administration purpose is owned and accessible only by the admin user/group.

This comment has been minimized.

@tallclair

tallclair May 9, 2018

Member

I'm not sure what this means. admin user/group seems very deployment specific.

This comment has been minimized.

@easeway

easeway May 9, 2018

Author

I will explain in the better way. This is for the file /etc/kubernetes/admin.conf which contains credentials to access the cluster as cluster-admin.

- LimitRanger
- NodeRestriction
- PodTolerationRestriction
- AlwaysPullImages

This comment has been minimized.

@tallclair
- PodSecurityPolicy
- NamespaceLifecycle
- NamespaceExists
- DenyEscalatingExec

This comment has been minimized.

@tallclair

tallclair May 9, 2018

Member

Maybe for isolated, but I don't think this is required for restricted.


*Conformance Profile: Sandboxed*

The container runtime must be something using HyperVisor or gVisor.

This comment has been minimized.

@tallclair

tallclair May 9, 2018

Member

I would just say TBD here, since we haven't defined sandboxes in k8s yet.


- Conformance Profiles are well defined and finalized
- Definition of security criteria are curated and documented
- Tests are added to conformance test suite to cover security criteria and categorized according to conformance profiles

This comment has been minimized.

@tallclair

tallclair May 9, 2018

Member

Which milestone are these for?
How will we measure success?

- Definition of security criteria are curated and documented
- Tests are added to conformance test suite to cover security criteria and categorized according to conformance profiles

## Alternatives

This comment has been minimized.

@tallclair

tallclair May 9, 2018

Member

Can you discuss how this compares with the CIS benchmark, and linters like kube-bench

This comment has been minimized.

@easeway

easeway May 9, 2018

Author

Added in Alternatives.

@easeway easeway force-pushed the easeway:kep-security-conformance branch from bca9266 to 932b436 May 21, 2018

@easeway

This comment has been minimized.

Copy link
Author

easeway commented May 22, 2018

/cc @destijl

@k8s-ci-robot k8s-ci-robot requested a review from destijl May 22, 2018

- Access prohibited information

It protects the components of:
- Kubernetes cluster

This comment has been minimized.

@tallclair

tallclair May 23, 2018

Member

Cluster isn't well defined. I think it's worth enumerating the components here.


This profile limits the compatibility/capabilities to workloads to prevent
them from compromising the cluster.
It's still possible a malicious workload will compromise other workloads.

This comment has been minimized.

@tallclair

tallclair May 23, 2018

Member

How are you defining workload here? If you can compromise a privileged workload, that's a pretty straightforward path to a full cluster compromise.

them from compromising the cluster.
It's still possible a malicious workload will compromise other workloads.
It's best for the use case to operate a secure Kubernetes cluster and share
with untrusted users without taking multi-tenancy into consideration.

This comment has been minimized.

@tallclair

tallclair May 23, 2018

Member

I'm confused by this. Isn't sharing the cluster with untrusted users what we call "hard multitenancy"?

This comment has been minimized.

@ericavonb

ericavonb May 25, 2018

I think this might be trying to say it's the best case given the current capabilities of Kubernetes and containers, and does not address additional hardening that multi-tenancy might require to be fully secured.


Pod creation with `allowPrivilegeEscalation` set to `true` in `SecurityContext` (Pod or container level)
should fail if there's no explicit RBAC associated with the Pod service account
(`default` or explicitly specified in `ServiceAccountName`).

This comment has been minimized.

@tallclair

tallclair May 23, 2018

Member

I mean we have e2e tests for PSP, RBAC, etc. If those tests don't provide sufficient coverage of the functionality, we should fix those tests. I think here you should just test 1) expected PSP is configured, and 2) PSP is enforced (a single check is sufficient).

Although actually, now that I say that I realize that you should be able to run a conformant cluster without using PSP - e.g. if you're enforcing that policy with a third party controller like OPA.

@tallclair
Copy link
Member

tallclair left a comment

I think this PR is conflating too many things, in particular the definition of security profiles crossed with the test mechanisms.

I can see 2 approaches -

  1. define the security profiles first, then once you have full buy-in define the tests
  2. scope this down to just the "essential" profile, i.e. the behaviors & settings we think every cluster should use.

Similar to `Isolated`, but using a different container runtime for better isolation,
and possibly offering better compatibility and capabilities.
For example, using hypervisors, gVisor etc. which provides an additional layer of protection.

This comment has been minimized.

@tallclair

tallclair May 23, 2018

Member

How are you going to test this? We've been talking about how to define sandboxes concretely, and that's proving to be difficult on its own. I'm not sure it's going to be possible to test for those properties.



Notes:
- the above statements exclude _root_ user who always have full access to the system.

This comment has been minimized.

@tallclair

tallclair May 23, 2018

Member

This statement isn't accurate. A root user running unconfined with full privileges in the "root" namespace has full access.

This comment has been minimized.

@easeway

easeway May 24, 2018

Author

Thanks!


*Conformance Profile: Essential*

The configuration files for API server, controller manager, scheduler and kubelet should have the correct setup of ownership and file permissions.

This comment has been minimized.

@tallclair

tallclair May 23, 2018

Member

I'm still not convinced that this section is going to be useful as a conformance test. I think this should be discussed with @kubernetes/sig-cluster-lifecycle-pr-reviews - as @liggitt mentioned we haven't tested detailed configuration like this in the past.

The test code will inspect the master/node system by first looking up the processes by names.
The names are default to `etcd`, `kube-apiserver`, `kube-controller-manager`, `kube-scheduler`, `kubelet`.
In the case when the cluster admin changes these names,
overriding mechanism (e.g. via environment variable) must be supported by test code.

This comment has been minimized.

@tallclair

tallclair May 23, 2018

Member

I'm worried you're going to end up needing to define the full cluster API to fully configure these tests...

*Conformance Profile: Essential*

Every namespace has a service account named `default`.
Without explicit permission grant from RBAC RoleBinding or ClusterRoleBinding,

This comment has been minimized.

@tallclair

tallclair May 23, 2018

Member

I mean this should just say "Without an explicit authorization grant, this service account doesn't has minimal privileges on the Kubernetes API"

The following are required:

- All communication over mTLS/TLS
- apiserver talks to etcd via HTTPS

This comment has been minimized.

@tallclair

tallclair May 23, 2018

Member

Why? If it's talking over a local socket this shouldn't matter.


The following are required:

- All communication over mTLS/TLS

This comment has been minimized.

@tallclair

tallclair May 23, 2018

Member

nit: just TLS

This comment has been minimized.

@easeway

easeway May 24, 2018

Author

I mean mTLS or TLS. It's OK to setup with stronger security both sides authenticate each other's certificates.

threat: it by-pass admission controls
- NamespaceAutoProvision
threat: it allows accidental namespace creation
- profiling

This comment has been minimized.

@tallclair

The following are required:

- RBAC authorizer

This comment has been minimized.

@tallclair

tallclair May 23, 2018

Member

I don't think we should require RBAC. We're already testing for authorization behavior, as long as that's enforced, do we care about the mechanism?

threat: API server may be flooded by event requests
- LimitRanger
threat: unconstrainted access to LimitRange objects
- NodeRestriction

This comment has been minimized.

@tallclair

tallclair May 23, 2018

Member

I think this should be moved to essential.

@easeway

This comment has been minimized.

Copy link
Author

easeway commented May 25, 2018

After discussion with @bgrant0607 and @tallclair, this proposal will focus on Kubernetes conformance. I'm updating the proposal to be decoupled from the Security Profile proposal.

@easeway easeway force-pushed the easeway:kep-security-conformance branch from 932b436 to 675c9a6 May 25, 2018

@k8s-ci-robot k8s-ci-robot added size/L and removed size/XL labels May 25, 2018

@easeway easeway force-pushed the easeway:kep-security-conformance branch from 675c9a6 to ca96225 May 25, 2018

@bgrant0607 bgrant0607 self-assigned this Jun 5, 2018

@jdumars jdumars added this to Backlog in KEP Tracking Jun 5, 2018


Configuring a Kubernetes cluster is complicated,
and it's very easy to mis-configure a cluster to be insecure.
The current Kubernetes conformance test suite barely covers security aspects.

This comment has been minimized.

@mayakacz

mayakacz Jun 12, 2018

Is this a problem we should be addressing?


### Goals

- Define the initial list (to evolve later) of criteria for minimal security requirements

This comment has been minimized.

@mayakacz

mayakacz Jun 12, 2018

is this tied 1:1 to the security profiles? i.e. is there a minimal security profile that would pass these tests? which one?

This comment has been minimized.

@easeway

easeway Jun 13, 2018

Author

No. Security profile is more implementation specific, as it defines non-portable implementation specific rules like RBAC objects.


## Proposal

### List of Criteria

This comment has been minimized.

@mayakacz

mayakacz Jun 12, 2018

Is this a complete list, or a starter list? (It seems you wanted to design the list of criteria elsewhere - where is that happenign?)

This comment has been minimized.

@easeway

easeway Jun 13, 2018

Author

It's a starter list.

@jdumars jdumars moved this from Backlog to In SIG Review in KEP Tracking Jun 25, 2018

@jdumars jdumars moved this from In SIG Review to In progress in KEP Tracking Jun 25, 2018

@fejta-bot

This comment has been minimized.

Copy link

fejta-bot commented Sep 11, 2018

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

@fejta-bot

This comment has been minimized.

Copy link

fejta-bot commented Oct 11, 2018

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

@justaugustus

This comment has been minimized.

Copy link
Member

justaugustus commented Oct 13, 2018

/kind kep
/remove-lifecycle rotten

@errordeveloper

This comment has been minimized.

Copy link
Member

errordeveloper commented Oct 15, 2018

@easeway any updates on this?

@easeway

This comment has been minimized.

Copy link
Author

easeway commented Oct 23, 2018

The scope of Security Profile was changed. This is no longer in scope. I will close this, and probably reopen if we decide to put this back.

@easeway easeway closed this Oct 23, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.