…9-upstream-release-1.8

Automatic merge from submit-queue.

Automated cherry pick of #52849

Cherry pick of #52849 on release-1.8.

#52849: PodSecurityPolicy: Do not mutate nil privileged field

This is a larger change than usual for a cherry-pick, but changes are isolated to the PSP component, the cherry-pick was clean, and this fixes severe usability issues with systems with more than one PSP. Would like to get feedback from community users making use of PSP and let the master PR soak as we consider this.

```release-note
PodSecurityPolicy: when multiple policies allow a submitted pod, priority is given to ones which do not require any fields in the pod spec to be defaulted. If the pod must be defaulted, the first policy (ordered by name) that allows the pod is used.
```

Automatic merge from submit-queue (batch tested with PRs 52367, 53363, 54989, 54872, 54643). 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>.

Basic GCE PodSecurityPolicy Config

**What this PR does / why we need it**:

This PR lays the foundation for enabling PodSecurityPolicy in GCE and other default deployments. The 3 commits are:

1. Add policies, roles & bindings for the default addons on GCE.
2. Enable the PSP admission controller & load the addon policies when the`ENABLE_POD_SECURITY_POLICY=true` environment variable is set.
3. Support the PodSecurityPolicy in the E2E environment & add PSP tests.

NOTES:

- ~~Depends on #52301 for privileged capabilities~~
- ~~Depends on #52849 for sane mutations~~
- ~~Depends on #53479 for aggregator tests to pass~~
- ~~Depends on #54175 for dedicated fluentd service~~ account
- This PR is a fork of #46064, credit to @Q-Lee

**Which issue this PR fixes**: #43538

**Release note**:
```release-note
Add support for PodSecurityPolicy on GCE: `ENABLE_POD_SECURITY_POLICY=true` enables the admission controller, and installs policies for default addons.
```

Automatic merge from submit-queue (batch tested with PRs 55557, 55504, 56269, 55604, 56202). 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>.

Create{Container,Pod}SecurityContext: modify a pod and don't return the annotations

**What this PR does / why we need it**:
Prior #52849 we couldn't modify a pod and had to return annotations from the methods. But now, as we always working with a copy of a pod, we can modify it directly and we don't need to copy&return annotations separately.

This PR simplifies the code by modifying a pod directly. Also it renames these methods and replaces returning of the `SecurityContext` by in-place modification.

In fact it reverts the changes from #30257

**Release note**:
```release-note
NONE
```

PTAL @liggitt @timstclair 
CC @simo5

…ring_pod_update

Automatic merge from submit-queue (batch tested with PRs 17856, 16934, 17979, 17993, 18001).

Improve the process of pod updates by preferring non-mutating SCCs and reducing pod mutations

This is adaptation of kubernetes/kubernetes#52849 to SCC.

Details (mostly copy&pasted from original PR):
- SCCs which allow the pod as-is (no defaulting/mutating) are preferred
- During update operations, when mutations to pod specs are disallowed, only non-mutating SCCs are used to validate the pod
- Removes unnecessary mutation of pods:
  - Determines effective security context for pods using a wrapper containing the pod and container security context, rather than building/setting a combined struct on every admission
  - Does not set `privileged: &false` on security contexts with `privileged: nil`
  - Does not set `runAsNonRoot: &true` on security contexts that already have a non-nil, non-0 runAsUser
  - Does not mutate/normalize container capabilities unless changes are required (missing `defaultAddCapabilities` or `requiredDropCapabilities`)

Fixes #16467