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

Seccomp #135

Open
22 tasks done
pweil- opened this issue Oct 25, 2016 · 143 comments
Open
22 tasks done

Seccomp #135

pweil- opened this issue Oct 25, 2016 · 143 comments
Assignees
Labels
kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API kind/feature Categorizes issue or PR as related to a new feature. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. sig/node Categorizes an issue or PR as relevant to SIG Node. stage/stable Denotes an issue tracking an enhancement targeted for Stable/GA status

Comments

@pweil-
Copy link
Member

pweil- commented Oct 25, 2016

Description

Seccomp support is providing the ability to define seccomp profiles and configure pods to run with those profiles. This includes the ability control usage of the profiles via PSP as well as maintaining the ability to run as unconfined or with the default container runtime profile.

KEP: sig-node/20190717-seccomp-ga.md
Latest PR to update the KEP: #1747

Progress Tracker

FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT

More advice:

Design

  • Once you get LGTM from a @kubernetes/feature-reviewers member, you can check this checkbox, and the reviewer will apply the "design-complete" label.

Coding

  • Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.
  • As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
    and sometimes http://github.com/kubernetes/contrib, or other repos.
  • When you are done with the code, apply the "code-complete" label.
  • When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
    check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
    testing. They won't do detailed code review: that already happened when your PRs were reviewed.
    When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

  • Write user docs and get them merged in.
  • User docs go into http://github.com/kubernetes/kubernetes.github.io.
  • When the feature has user docs, please add a comment mentioning @kubernetes/docs.
  • When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.
@pweil-
Copy link
Member Author

pweil- commented Oct 25, 2016

@derekwaynecarr @sttts @erictune didn't see an issue for this but it is already in alpha. Creating this as the reminder to push it through to beta and stable.

@sttts could you provide the appropriate links to docs and PRs? I think you are closest to this code.

@derekwaynecarr
Copy link
Member

derekwaynecarr commented Oct 25, 2016

@pweil- @sttts - per our discussion, this is a feature we would like to sponsor in Kubernetes 1.6 under @kubernetes/sig-node

@idvoretskyi
Copy link
Member

idvoretskyi commented Oct 26, 2016

@pweil- @derekwaynecarr please, confirm that this feature has to be set with 1.6 milestone.

@sttts
Copy link
Contributor

sttts commented Oct 26, 2016

@idvoretskyi we target to move it to beta for 1.6.

@idvoretskyi idvoretskyi added this to the next-milestone milestone Oct 26, 2016
@idvoretskyi
Copy link
Member

idvoretskyi commented Oct 26, 2016

@sttts thanks.

@idvoretskyi idvoretskyi modified the milestones: v1.6, next-milestone Dec 13, 2016
@idvoretskyi idvoretskyi added stage/beta Denotes an issue tracking an enhancement targeted for Beta status sig/node Categorizes an issue or PR as relevant to SIG Node. labels Jan 10, 2017
@idvoretskyi idvoretskyi modified the milestones: next-milestone, v1.6 Feb 28, 2017
@bgrant0607
Copy link
Member

bgrant0607 commented May 30, 2017

@calebamiles calebamiles added the sig/auth Categorizes an issue or PR as relevant to SIG Auth. label Jul 26, 2017
@calebamiles calebamiles modified the milestones: 1.8, next-milestone Jul 26, 2017
@idvoretskyi
Copy link
Member

idvoretskyi commented Sep 5, 2017

@pweil- any updates for 1.8? Is this feature still on track for the release?

@pweil-
Copy link
Member Author

pweil- commented Sep 11, 2017

@idvoretskyi this was not a priority for 1.8. @php-coder can you add a card to this for our PM planning? We need to stop letting this fall through the cracks and get it moved to beta and GA.

@idvoretskyi
Copy link
Member

idvoretskyi commented Sep 12, 2017

@pweil- if this feature is not planned for 1.8 - please, update the milestone with the "next-milestone" or "1.9"

@tallclair
Copy link
Member

tallclair commented Sep 23, 2017

I'd like to see this get to beta. Priorities (or requirements) for that include:

  1. Annotations (Pod & PodSecurityPolicy) must be moved to fields on the container SecurityContext (see https://github.com/kubernetes/community/blob/master/contributors/devel/api_changes.md#alpha-field-in-existing-api-version)
  2. Settle on the OCI spec seccomp format, and define a Kubernetes default profile (can we reuse Docker's?) Proposal: spec the seccomp profile format kubernetes#39128
    a. Figure out how the Kubernetes profile is delivered to the container runtime via CRI (/cc @yujuhong @Random-Liu )
    b. docker/default should still be allowed if the runtime is docker (for backwards compatibility)
  3. The Kubernetes default profile should be the new default. For backwards compatibility, this MUST be optional behavior (i.e. flag controlled). Change seccomp default to 'docker/default' kubernetes#39845

Is anyone interested in driving this work for the 1.9 (or 1.10) milestone? @jessfraz @kubernetes/sig-auth-feature-requests and @kubernetes/sig-node-feature-requests I'm looking at you 😉

Also relevant: kubernetes/community#660 (do we need to settle the decisions in that PR before proceeding?)

@tallclair
Copy link
Member

tallclair commented Sep 23, 2017

/cc @destijl

@jessfraz
Copy link

jessfraz commented Sep 24, 2017

@jessfraz
Copy link

jessfraz commented Oct 18, 2017

ok I will update the proposal and start on this tomorrow if no one else will ;)

saschagrunert added a commit to saschagrunert/kubernetes that referenced this issue Jul 7, 2022
We now partly drop the support for seccomp annotations which is planned
for v1.25 as part of the KEP:

kubernetes/enhancements#135

Pod security policies are not touched by this change and therefore we
have to keep the annotation key constants.

Making the annotations fully non-functional will be deferred to a
future release.

Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
saschagrunert added a commit to saschagrunert/kubernetes that referenced this issue Jul 18, 2022
We now partly drop the support for seccomp annotations which is planned
for v1.25 as part of the KEP:

kubernetes/enhancements#135

Pod security policies are not touched by this change and therefore we
have to keep the annotation key constants.

Making the annotations fully non-functional will be deferred to a
future release.

Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
saschagrunert added a commit to saschagrunert/kubernetes that referenced this issue Jul 18, 2022
We now partly drop the support for seccomp annotations which is planned
for v1.25 as part of the KEP:

kubernetes/enhancements#135

Pod security policies are not touched by this change and therefore we
have to keep the annotation key constants.

Making the annotations fully non-functional will be deferred to a
future release.

Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
saschagrunert added a commit to saschagrunert/kubernetes that referenced this issue Jul 19, 2022
We now partly drop the support for seccomp annotations which is planned
for v1.25 as part of the KEP:

kubernetes/enhancements#135

Pod security policies are not touched by this change and therefore we
have to keep the annotation key constants.

Making the annotations fully non-functional will be deferred to a
future release.

Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
saschagrunert added a commit to saschagrunert/kubernetes that referenced this issue Jul 19, 2022
We now partly drop the support for seccomp annotations which is planned
for v1.25 as part of the KEP:

kubernetes/enhancements#135

Pod security policies are not touched by this change and therefore we
have to keep the annotation key constants.

Making the annotations fully non-functional will be deferred to a
future release.

Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
saschagrunert added a commit to saschagrunert/kubernetes that referenced this issue Jul 20, 2022
We now partly drop the support for seccomp annotations which is planned
for v1.25 as part of the KEP:

kubernetes/enhancements#135

Pod security policies are not touched by this change and therefore we
have to keep the annotation key constants.

This means we only allow the usage of the annotations for backwards
compatibility reasons while the synchronization of the field to
annotation is no longer supported. Using the annotations for static pods
is also not supported any more.

Making the annotations fully non-functional will be deferred to a
future release.

Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
saschagrunert added a commit to saschagrunert/kubernetes that referenced this issue Jul 29, 2022
We now partly drop the support for seccomp annotations which is planned
for v1.25 as part of the KEP:

kubernetes/enhancements#135

Pod security policies are not touched by this change and therefore we
have to keep the annotation key constants.

This means we only allow the usage of the annotations for backwards
compatibility reasons while the synchronization of the field to
annotation is no longer supported. Using the annotations for static pods
is also not supported any more.

Making the annotations fully non-functional will be deferred to a
future release.

Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
saschagrunert added a commit to saschagrunert/kubernetes that referenced this issue Aug 1, 2022
We now partly drop the support for seccomp annotations which is planned
for v1.25 as part of the KEP:

kubernetes/enhancements#135

Pod security policies are not touched by this change and therefore we
have to keep the annotation key constants.

This means we only allow the usage of the annotations for backwards
compatibility reasons while the synchronization of the field to
annotation is no longer supported. Using the annotations for static pods
is also not supported any more.

Making the annotations fully non-functional will be deferred to a
future release.

Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
k8s-publishing-bot pushed a commit to kubernetes/pod-security-admission that referenced this issue Aug 1, 2022
We now partly drop the support for seccomp annotations which is planned
for v1.25 as part of the KEP:

kubernetes/enhancements#135

Pod security policies are not touched by this change and therefore we
have to keep the annotation key constants.

This means we only allow the usage of the annotations for backwards
compatibility reasons while the synchronization of the field to
annotation is no longer supported. Using the annotations for static pods
is also not supported any more.

Making the annotations fully non-functional will be deferred to a
future release.

Signed-off-by: Sascha Grunert <sgrunert@redhat.com>

Kubernetes-commit: 584783ee9f89fbff58bb69f6107db18f18ba8746
@k8s-triage-robot
Copy link

k8s-triage-robot commented Aug 3, 2022

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

  • After 90d of inactivity, lifecycle/stale is applied
  • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
  • After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

  • Mark this issue or PR as fresh with /remove-lifecycle stale
  • Mark this issue or PR as rotten with /lifecycle rotten
  • Close this issue or PR with /close
  • Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Aug 3, 2022
@pjbgf
Copy link
Member

pjbgf commented Aug 3, 2022

/remove-lifecycle stale

@saschagrunert saschagrunert removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Aug 4, 2022
@tallclair
Copy link
Member

tallclair commented Aug 24, 2022

/lifecycle frozen

@pjbgf @saschagrunert Are we just keeping this open to track the annotation removal at this point?

I think the only remaining task is to stop copying annotations to fields, in v1.27?

@k8s-ci-robot k8s-ci-robot added the lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. label Aug 24, 2022
@saschagrunert
Copy link
Member

saschagrunert commented Aug 25, 2022

@pjbgf @saschagrunert Are we just keeping this open to track the annotation removal at this point?

I think the only remaining task is to stop copying annotations to fields, in v1.27?

Yep, exactly let's keep it open to track this last point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API kind/feature Categorizes issue or PR as related to a new feature. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. sig/node Categorizes an issue or PR as relevant to SIG Node. stage/stable Denotes an issue tracking an enhancement targeted for Stable/GA status
Projects
None yet
Development

No branches or pull requests