b0eb7d884d
Automatic merge from submit-queue (batch tested with PRs 53454, 53446, 52935, 53443, 52917). If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>. Use pointer for PSP allow escalation Fixes #53437 The `AllowPrivilegeEscalation` field was added to PodSpec and PodSecurityPolicySpec in 1.8.0. In order to remain compatible with pre-1.8.0 behavior, PodSecurityPolicy objects created against a previous release must not restrict this field, which means the field must default to true in PodSecurityPolicySpec. However, the field was added as a `bool`, not a `*bool`, which means that no defaulting is possible. We have two options: 1. Require all pre-existing PodSecurityPolicy objects that intend to allow privileged permissions to update to set this new field to true 2. Change the field to a `*bool` and default it to true. This PR does the latter. With this change, we have the following behavior: A 1.8.1+ client/server now has three ways to serialize: * `nil` values are dropped from serialization (because `omitempty`), which is interpreted correctly by other 1.8.1+ clients/servers, and is interpreted as false by 1.8.0 * `false` values are serialized and interpreted correctly by all clients/servers * `true` values are serialized and interpreted correctly by all clients/servers A 1.8.0 client/server has two ways to serialize: * `false` values are dropped from serialization (because `omitempty`), which is interpreted as `false` by other 1.8.0 clients/servers, but as `nil` (and therefore defaulting to true) by 1.8.1+ clients/servers * `true` values are serialized and interpreted correctly by all clients/servers The primary concern is the 1.8.0 server dropping the `false` value from serialization, but I consider the compatibility break with pre-1.8 behavior to be more severe, especially if we can resolve the regression in an immediate point release. ```release-note PodSecurityPolicy: Fixes a compatibility issue that caused policies that previously allowed privileged pods to start forbidding them, due to an incorrect default value for `allowPrivilegeEscalation`. PodSecurityPolicy objects defined using a 1.8.0 client or server that intended to set `allowPrivilegeEscalation` to `false` must be reapplied after upgrading to 1.8.1. ```
External Repository Staging Area
This directory is the staging area for packages that have been split to their own repository. The content here will be periodically published to respective top-level k8s.io repositories.
Repositories currently staged here:
k8s.io/apiextensions-apiserverk8s.io/apik8s.io/apimachineryk8s.io/apiserverk8s.io/client-gok8s.io/kube-aggregatork8s.io/code-generator(about to be published)k8s.io/metricsk8s.io/sample-apiserver
The code in the staging/ directory is authoritative, i.e. the only copy of the code. You can directly modify such code.
Using staged repositories from Kubernetes code
Kubernetes code uses the repositories in this directory via symlinks in the
vendor/k8s.io directory into this staging area. For example, when
Kubernetes code imports a package from the k8s.io/client-go repository, that
import is resolved to staging/src/k8s.io/client-go relative to the project
root:
// pkg/example/some_code.go
package example
import (
"k8s.io/client-go/dynamic" // resolves to staging/src/k8s.io/client-go/dynamic
)
Once the change-over to external repositories is complete, these repositories
will actually be vendored from k8s.io/<package-name>.