The deployment with configuration that use the SCC anyuid and have the "seccompProfile" configured, will not be admitted to the cluster with the following error.
```
unable to validate against any security context constraint: [pod.metadata.annotations[seccomp.security.alpha.kubernetes.io/pod]: Forbidden: seccomp may not be set, pod.metadata.annotations[container.seccomp.security.alpha.kubernetes.io/test]
```

The SCC anyuid doesn't have the "seccompProfiles" configured, hence the pod will be rejected.
My question is - it is something that works as expected? Why the anyuid doesn't specify the seccomp profiles as the latest "-v2" SCCs do?

It causes an issue where some deployments do have seccompProfile define in the yaml, however, they need to use the anyuid SCC.
    

Tested on versions:
- 4.15
- 4.16
    

- create deployment, assign the anyuid SCC, configure "runAsUser", "fsGroup" and "seccompProfile=runtime/default" check if the pod is admitted
    

    1. Create deployment
# oc new-project testing-anyuid-scc-seccomp
# oc create deployment test --replicas=0 --image=registry.redhat.io/rhel9/support-tools -- sleep infinity

    2. Create SA
# oc create sa test
# oc adm policy add-scc-to-user anyuid -z test

    3. Modify the deployment
# oc patch deployment test --type=merge -p '{"spec":{"template":{"spec":{"serviceAccount":"test","serviceAccountName":"test"}}}}'
# oc patch deployment test --type=merge -p '{"spec":{"template":{"spec":{"securityContext":{"runAsUser":1002,"fsGroup":1002,"seccompProfile":{"type":"RuntimeDefault"}}}}}}'

    4. Scale the pod
# oc scale deployment test --replicas=1

    5. Check the status
# oc get deployment test -o json | jq -r '.status.conditions[] | select(.reason=="FailedCreate") | .message'

    

The pod is not admitted.
    

Is it expected behavior?
    

Simple workaround exists to make a copy of the anyuid scc and modify the seccompProfiles to "- runtime/default".
# oc patch scc anyuid-seccomp --type=merge -p '{"seccompProfiles":["runtime/default"]}'