mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
126 lines
4.2 KiB
Plaintext
126 lines
4.2 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * authentication/managing-security-context-constraints.adoc
|
|
|
|
[id="security-context-constraints-example_{context}"]
|
|
= Example security context constraints
|
|
|
|
The following examples show the security context constraints (SCC) format and
|
|
annotations:
|
|
|
|
.Annotated `privileged` SCC
|
|
[source,yaml]
|
|
----
|
|
allowHostDirVolumePlugin: true
|
|
allowHostIPC: true
|
|
allowHostNetwork: true
|
|
allowHostPID: true
|
|
allowHostPorts: true
|
|
allowPrivilegedContainer: true
|
|
allowedCapabilities: <1>
|
|
- '*'
|
|
apiVersion: security.openshift.io/v1
|
|
defaultAddCapabilities: [] <2>
|
|
fsGroup: <3>
|
|
type: RunAsAny
|
|
groups: <4>
|
|
- system:cluster-admins
|
|
- system:nodes
|
|
kind: SecurityContextConstraints
|
|
metadata:
|
|
annotations:
|
|
kubernetes.io/description: 'privileged allows access to all privileged and host
|
|
features and the ability to run as any user, any group, any fsGroup, and with
|
|
any SELinux context. WARNING: this is the most relaxed SCC and should be used
|
|
only for cluster administration. Grant with caution.'
|
|
creationTimestamp: null
|
|
name: privileged
|
|
priority: null
|
|
readOnlyRootFilesystem: false
|
|
requiredDropCapabilities: null <5>
|
|
runAsUser: <6>
|
|
type: RunAsAny
|
|
seLinuxContext: <7>
|
|
type: RunAsAny
|
|
seccompProfiles:
|
|
- '*'
|
|
supplementalGroups: <8>
|
|
type: RunAsAny
|
|
users: <9>
|
|
- system:serviceaccount:default:registry
|
|
- system:serviceaccount:default:router
|
|
- system:serviceaccount:openshift-infra:build-controller
|
|
volumes: <10>
|
|
- '*'
|
|
----
|
|
|
|
<1> A list of capabilities that a pod can request. An empty list means
|
|
that none of capabilities can be requested while the special symbol `***`
|
|
allows any capabilities.
|
|
<2> A list of additional capabilities that are added to any pod.
|
|
<3> The `FSGroup` strategy, which dictates the allowable values for the
|
|
security context.
|
|
<4> The groups that can access this SCC.
|
|
<5> A list of capabilities to drop from a pod. Or, specify `ALL` to drop all
|
|
capabilities.
|
|
<6> The `runAsUser` strategy type, which dictates the allowable values for the
|
|
security context.
|
|
//could use the available strategies
|
|
<7> The `seLinuxContext` strategy type, which dictates the allowable values for
|
|
the security context.
|
|
<8> The `supplementalGroups` strategy, which dictates the allowable supplemental
|
|
groups for the security context.
|
|
<9> The users who can access this SCC.
|
|
<10> The allowable volume types for the security context. In the example, `*` allows the use of all volume types.
|
|
|
|
The `users` and `groups` fields on the SCC control which users can access the
|
|
SCC.
|
|
By default, cluster administrators, nodes, and the build controller are granted
|
|
access to the privileged SCC. All authenticated users are granted access to the
|
|
`restricted-v2` SCC.
|
|
|
|
.Without explicit `runAsUser` setting
|
|
[source,yaml]
|
|
----
|
|
apiVersion: v1
|
|
kind: Pod
|
|
metadata:
|
|
name: security-context-demo
|
|
spec:
|
|
securityContext: <1>
|
|
containers:
|
|
- name: sec-ctx-demo
|
|
image: gcr.io/google-samples/node-hello:1.0
|
|
----
|
|
<1> When a container or pod does not request a user ID under which it should be run,
|
|
the effective UID depends on the SCC that emits this pod. Because the `restricted-v2` SCC
|
|
is granted to all authenticated users by default, it will be available to all
|
|
users and service accounts and used in most cases. The `restricted-v2` SCC uses
|
|
`MustRunAsRange` strategy for constraining and defaulting the possible values of
|
|
the `securityContext.runAsUser` field. The admission plugin will look for the
|
|
`openshift.io/sa.scc.uid-range` annotation on the current project to populate
|
|
range fields, as it does not provide this range. In the end, a container will
|
|
have `runAsUser` equal to the first value of the range that is
|
|
hard to predict because every project has different ranges.
|
|
|
|
.With explicit `runAsUser` setting
|
|
[source,yaml]
|
|
----
|
|
apiVersion: v1
|
|
kind: Pod
|
|
metadata:
|
|
name: security-context-demo
|
|
spec:
|
|
securityContext:
|
|
runAsUser: 1000 <1>
|
|
containers:
|
|
- name: sec-ctx-demo
|
|
image: gcr.io/google-samples/node-hello:1.0
|
|
----
|
|
<1> A container or pod that requests a specific user ID will be accepted by
|
|
{product-title} only when a service account or a user is granted access to a SCC
|
|
that allows such a user ID. The SCC can allow arbitrary IDs, an ID that falls
|
|
into a range, or the exact user ID specific to the request.
|
|
|
|
This configuration is valid for SELinux, fsGroup, and Supplemental Groups.
|