Repository: kubernetes
Issue: Incorrect validation of `allowPrivilegeEscalation` with `SYS_ADMIN` capability
Labels: kind/bug,sig/node,sig/security,needs-triage

### What happened?

Validation logic to disallow `allowPrivilegeEscalation: false` in combination with `SYS_ADMIN` capability checks for `CAP_SYS_ADMIN` instead of `SYS_ADMIN` (see [security context validation](https://github.com/kubernetes/kubernetes/blob/d17f3ba/pkg/apis/core/validation/validation.go#L6823)).

Adding `CAP_SYS_ADMIN` to the security context does not add the `cap_sys_admin` capability to the container, while the `SYS_ADMIN` capability does add it.

⚠️ Tested with containerd, CRI-O seems to "correctly" add the capability when using `CAP_SYS_ADMIN`.

### What did you expect to happen?

A container that has a `securityContext` set, with both `allowPrivilegedEscalation` set to `false` and configuration to receive `cap_sys_admin` privileges, should be rejected.

### How can we reproduce it (as minimally and precisely as possible)?

Following pod logs the current capabilities of the container and then exits.

example pod, that is rejected:
```yaml
apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
  - name: alpine
    image: alpine
    command: ['sh', '-c', 'apk add -U libcap && capsh --print']
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
        - "ALL"
        add:
        - "CAP_SYS_ADMIN"
```

example pod, that is scheduled with `cap_sys_admin` capability and `allowPrivilegeEscalation`:
```yaml
apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
  - name: alpine
    image: alpine
    command: ['sh', '-c', 'apk add -U libcap && capsh --print']
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
        - "ALL"
        add:
        - "SYS_ADMIN"
```
> Current: cap_sys_admin=ep

### Anything else we need to know?

This is a small fix for a single incorrect validation, but the problem is that it's possible to create containers that do not receive the expected capabilities without receiving a warning (see [related discussion](https://github.com/kubernetes/kubernetes/pull/117812#discussion_r1238776853)).

There is a warning, that "...you must omit the `CAP_` portion of the constant..." in the how to [set capabilities for a container](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container) documentation, but none of that is validated.

I will create a PR for this and created a separate issue to propose an enhancement for capability validation in general: https://github.com/kubernetes/kubernetes/issues/119569

### Kubernetes version

<details>

```console
$ kubectl version
WARNING: This version information is deprecated and will be replaced with the output from kubectl version --short.  Use --output=yaml|json to get the full version.
Client Version: version.Info{Major:"1", Minor:"27", GitVersion:"v1.27.2", GitCommit:"7f6f68fdabc4df88cfea2dcf9a19b2b830f1e647", GitTreeState:"clean", BuildDate:"2023-05-17T14:20:07Z", GoVersion:"go1.20.4", Compiler:"gc", Platform:"darwin/amd64"}
Kustomize Version: v5.0.1
Server Version: version.Info{Major:"1", Minor:"27", GitVersion:"v1.27.2-gke.2100", GitCommit:"00dd416d1e3300d98717d48686c7cde7cb5dd6b5", GitTreeState:"clean", BuildDate:"2023-06-14T09:21:52Z", GoVersion:"go1.20.4 X:boringcrypto", Compiler:"gc", Platform:"linux/amd64"}
```

</details>


### Cloud provider

<details>
GKE

Should be unrelated to cloud provider, as it's part of the core validation logic.
</details>


### OS version

<details>

```console
# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here
```

</details>


### Install tools

<details>

</details>


### Container runtime (CRI) and version (if applicable)

<details>

</details>


### Related plugins (CNI, CSI, ...) and versions (if applicable)

<details>

</details>