Change:
Message: "Scheduling is blocked due to non-empty scheduling gates", }) } <del> // applySeccompVersionSkew implements the version skew behavior described in: // https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/135-seccomp#version-skew-strategy // Note that we dropped copying the field to annotation synchronization in // v1.25 with the functional removal of the annotations. func applySeccompVersionSkew(pod *api.Pod) { // get possible annotation and field annotation, hasAnnotation := pod.Annotations[v1.SeccompPodAnnotationKey] hasField := false if pod.Spec.SecurityContext != nil && pod.Spec.SecurityContext.SeccompProfile != nil { hasField = true } // sync field and annotation if hasAnnotation && !hasField { newField := seccompFieldForAnnotation(annotation) if newField != nil { if pod.Spec.SecurityContext == nil { pod.Spec.SecurityContext = &api.PodSecurityContext{} } pod.Spec.SecurityContext.SeccompProfile = newField } } // Handle the containers of the pod podutil.VisitContainers(&pod.Spec, podutil.AllFeatureEnabledContainers(), func(ctr *api.Container, _ podutil.ContainerType) bool { // get possible annotation and field key := api.SeccompContainerAnnotationKeyPrefix + ctr.Name annotation, hasAnnotation := pod.Annotations[key] hasField := false if ctr.SecurityContext != nil && ctr.SecurityContext.SeccompProfile != nil { hasField = true } // sync field and annotation if hasAnnotation && !hasField { newField := seccompFieldForAnnotation(annotation) if newField != nil { if ctr.SecurityContext == nil { ctr.SecurityContext = &api.SecurityContext{} } ctr.SecurityContext.SeccompProfile = newField } } return true }) } // seccompFieldForAnnotation takes a pod annotation and returns the converted // seccomp profile field. func seccompFieldForAnnotation(annotation string) *api.SeccompProfile { // If only seccomp annotations are specified, copy the values into the // corresponding fields. This ensures that existing applications continue // to enforce seccomp, and prevents the kubelet from needing to resolve // annotations & fields. if annotation == v1.SeccompProfileNameUnconfined { return &api.SeccompProfile{Type: api.SeccompProfileTypeUnconfined} } if annotation == api.SeccompProfileRuntimeDefault || annotation == api.DeprecatedSeccompProfileDockerDefault { return &api.SeccompProfile{Type: api.SeccompProfileTypeRuntimeDefault} } if strings.HasPrefix(annotation, v1.SeccompLocalhostProfileNamePrefix) { localhostProfile := strings.TrimPrefix(annotation, v1.SeccompLocalhostProfileNamePrefix) if localhostProfile != "" { return &api.SeccompProfile{ Type:             api.SeccompProfileTypeLocalhost, LocalhostProfile: &localhostProfile, } } } // we can only reach this code path if the localhostProfile name has a zero // length or if the annotation has an unrecognized value return nil } </del>

Discussion:
Graduate seccomp to GA, as defined on the respective . This is an umbrella issue to track all outstanding work. [x] API Server changes (MERGED) [x] Kubelet changes (MERGED) [x] Mark flag as deprecated (MERGED) [x] Update PSP to support seccomp fields (MERGED) [x] Document Kubernetes seccomp support (MERGED)[x] Add seccomp least privilege for docker sandbox (MERGED) [x] Add seccomp least privilege for kuberuntime (MERGED) ) /area kubelet /area kubelet-api /sig node /area security /assign
/cc
just a heads up that we have concluded all the core items for seccomp to go GA. There are still 2 pending PRs that ideally would also go in 1.19, but we are waiting for them to be reviewed: and
needs to be rebased apparently and isn't just waiting in the merge pool as verify is not passing.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
I think the warning mechanism was blocked by a not existing API. This is now tracked in
/remove-lifecycle stale
Updated the description to given that the warning mechanism is now set to that milestone.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
/remove-lifecycle stale
/priority backlog
/triage accepted
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, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
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, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
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, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
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, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at .

/lifecycle stale [1]:
/remove-lifecycle stale
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, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
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, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
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, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/lifecycle frozen What is the remaining work here?
I guess we have to follow-up on and implement: I can take care of that if we agree that we want to ship that in 1.27. /cc