Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

このコンテンツは選択した言語では利用できません。

Chapter 7. Managing Security Context Constraints

7.1. Overview
リンクのコピー

Security context constraints allow administrators to control permissions for pods. To learn more about this API type, see the security context constraints (SCCs) architecture documentation. You can manage SCCs in your instance as normal API objects using the CLI.

Note

You must have cluster-admin privileges to manage SCCs.

7.2. Listing Security Context Constraints
リンクのコピー

To get a current list of SCCs: 

$ oc get scc

NAME               PRIV      CAPS      SELINUX     RUNASUSER          FSGROUP     SUPGROUP    PRIORITY   READONLYROOTFS   VOLUMES
anyuid             false     []        MustRunAs   RunAsAny           RunAsAny    RunAsAny    10         false            [configMap downwardAPI emptyDir persistentVolumeClaim secret]
hostaccess         false     []        MustRunAs   MustRunAsRange     MustRunAs   RunAsAny    <none>     false            [configMap downwardAPI emptyDir hostPath persistentVolumeClaim secret]
hostmount-anyuid   false     []        MustRunAs   RunAsAny           RunAsAny    RunAsAny    <none>     false            [configMap downwardAPI emptyDir hostPath persistentVolumeClaim secret]
hostnetwork        false     []        MustRunAs   MustRunAsRange     MustRunAs   MustRunAs   <none>     false            [configMap downwardAPI emptyDir persistentVolumeClaim secret]
nonroot            false     []        MustRunAs   MustRunAsNonRoot   RunAsAny    RunAsAny    <none>     false            [configMap downwardAPI emptyDir persistentVolumeClaim secret]
privileged         true      []        RunAsAny    RunAsAny           RunAsAny    RunAsAny    <none>     false            [*]
restricted         false     []        MustRunAs   MustRunAsRange     MustRunAs   RunAsAny    <none>     false            [configMap downwardAPI emptyDir persistentVolumeClaim secret]
Copy to Clipboard Toggle word wrap

7.3. Examining a Security Context Constraints Object
リンクのコピー

To examine a particular SCC, use oc get, oc describe, oc export, or oc edit. For example, to examine the restricted SCC: 

$ oc describe scc restricted

Name:						restricted
Priority:					<none>
Access:
  Users:					<none>
  Groups:					system:authenticated
Settings:
  Allow Privileged:				false
  Default Add Capabilities:			<none>
  Required Drop Capabilities:			<none>
  Allowed Capabilities:				<none>
  Allowed Volume Types:				awsElasticBlockStore,azureFile,cephFS,cinder,configMap,downwardAPI,emptyDir,fc,flexVolume,flocker,gcePersistentDisk,gitRepo,glusterfs,iscsi,nfs,persistentVolumeClaim,rbd,secret
  Allow Host Network:				false
  Allow Host Ports:				false
  Allow Host PID:				false
  Allow Host IPC:				false
  Read Only Root Filesystem:			false
  Run As User Strategy: MustRunAsRange
    UID:					<none>
    UID Range Min:				<none>
    UID Range Max:				<none>
  SELinux Context Strategy: MustRunAs
    User:					<none>
    Role:					<none>
    Type:					<none>
    Level:					<none>
  FSGroup Strategy: RunAsAny
    Ranges:					<none>
  Supplemental Groups Strategy: RunAsAny
    Ranges:					<none>
Copy to Clipboard Toggle word wrap
Note

In order to preserve customized SCCs during upgrades, do not edit settings on the default SCCs other than priority, users, groups, labels, and annotations.

7.4. Creating New Security Context Constraints
リンクのコピー

To create a new SCC:

  1. Define the SCC in a JSON or YAML file:

    Example 7.1. Security Context Constraint Object Definition

    kind: SecurityContextConstraints
apiVersion: v1
metadata:
  name: scc-admin
allowPrivilegedContainer: true
runAsUser:
  type: RunAsAny
seLinuxContext:
  type: RunAsAny
fsGroup:
  type: RunAsAny
supplementalGroups:
  type: RunAsAny
users:
- my-admin-user
groups:
- my-admin-group
    Copy to Clipboard Toggle word wrap

    Optionally, you can add drop capabilities to an SCC by setting the requiredDropCapabilities: field with the desired values. Any specified capabilities will be dropped from the container. For example, to create an SCC with the KILL, MKNOD, and SYS_CHROOT required drop capabilities, add the following to the SCC object: 

    requiredDropCapabilities:
- KILL
- MKNOD
- SYS_CHROOT
    Copy to Clipboard Toggle word wrap

    You can see the list of possible values in the Docker documentation.

  2. Then, run oc create passing the file to create it: 

    $ oc create -f scc_admin.yaml
securitycontextconstraints/scc-admin
    Copy to Clipboard Toggle word wrap

  3. Verify that the SCC was created: 

    $ oc get scc
NAME         PRIV      CAPS      HOSTDIR   SELINUX     RUNASUSER
privileged   true      []        true      RunAsAny    RunAsAny
restricted   false     []        false     MustRunAs   MustRunAsRange
scc-admin    true      []        false     RunAsAny    RunAsAny
    Copy to Clipboard Toggle word wrap

7.5. Deleting Security Context Constraints
リンクのコピー

To delete an SCC: 

$ oc delete scc <scc_name>
Copy to Clipboard Toggle word wrap
Note

If you delete the default SCCs, they will not be regenerated upon restart, unless you delete all SCCs. If any constraint already exists within the system, no regeneration will take place.

7.6. Updating Security Context Constraints
リンクのコピー

To update an existing SCC: 

$ oc edit scc <scc_name>
Copy to Clipboard Toggle word wrap
Note

In order to preserve customized SCCs during upgrades, do not edit settings on the default SCCs other than priority, users, and groups.

7.7. Updating the Default Security Context Constraints
リンクのコピー

Default SCCs will be created when the master is started if they are missing. To reset SCCs to defaults, or update existing SCCs to new default definitions after an upgrade you may:

  1. Delete any SCC you would like to be reset and let it be recreated by restarting the master
  2. Use the oadm policy reconcile-sccs command

The oadm policy reconcile-sccs command will set all SCC policies to the default values but retain any additional users, groups, labels, and annotations as well as priorities you may have already set. To view which SCCs will be changed you may run the command with no options or by specifying your preferred output with the -o <format> option.

After reviewing it is recommended that you back up your existing SCCs and then use the --confirm option to persist the data.

Note

If you would like to reset priorities and grants, use the --additive-only=false option.

Note

If you have customized settings other than priority, users, groups, labels, or annotations in an SCC, you will lose those settings when you reconcile.

7.8. How Do I?
リンクのコピー

The following describe common scenarios and procedures using SCCs.

7.8.1. Grant Access to the Privileged SCC
リンクのコピー

In some cases, an administrator might want to allow users or groups outside the administrator group access to create more privileged pods. To do so, you can:

  1. Determine the user or group you would like to have access to the SCC.

  2. Run: 

    $ oadm policy add-scc-to-user <scc_name> <user_name>
$ oadm policy add-scc-to-group <scc_name> <group_name>
    Copy to Clipboard Toggle word wrap

For example, to allow the e2e-user access to the privileged SCC, run: 

$ oadm policy add-scc-to-user privileged e2e-user
Copy to Clipboard Toggle word wrap

7.8.2. Grant a Service Account Access to the Privileged SCC
リンクのコピー

First, create a service account. For example, to create service account mysvcacct in project myproject: 

$ oc create serviceaccount mysvcacct -n myproject
Copy to Clipboard Toggle word wrap

Then, add the service account to the privileged SCC. 

$ oadm policy add-scc-to-user privileged system:serviceaccount:myproject:mysvcacct
Copy to Clipboard Toggle word wrap

7.8.3. Enable Images to Run with USER in the Dockerfile
リンクのコピー

To relax the security in your cluster so that images are not forced to run as a pre-allocated UID, without granting everyone access to the privileged SCC:

  1. Grant all authenticated users access to the anyuid SCC: 

    $ oadm policy add-scc-to-group anyuid system:authenticated
    Copy to Clipboard Toggle word wrap
Warning

This allows images to run as the root UID if no USER is specified in the Dockerfile.

7.8.4. Enable Container Images that Require Root
リンクのコピー

Some container images (examples: postgres and redis) require root access and have certain expectations about how volumes are owned. For these images, add the service account to the anyuid SCC. 

$ oadm policy add-scc-to-user anyuid system:serviceaccount:myproject:mysvcacct
Copy to Clipboard Toggle word wrap

7.8.5. Use --mount-host on the Registry
リンクのコピー

It is recommended that persistent storage using PersistentVolume and PersistentVolumeClaim objects be used for registry deployments. If you are testing and would like to instead use the oadm registry command with the --mount-host option, you must first create a new service account for the registry and add it to the privileged SCC. See the Administrator Guide for full instructions.

7.8.6. Provide Additional Capabilities
リンクのコピー

In some cases, an image may require capabilities that Docker does not provide out of the box. You can provide the ability to request additional capabilities in the pod specification which will be validated against an SCC.

Important

This allows images to run with elevated capabilities and should be used only if necessary. You should not edit the default restricted SCC to enable additional capabilities.

When used in conjunction with a non-root user, you must also ensure that the file that requires the additional capability is granted the capabilities using the setcap command. For example, in the Dockerfile of the image: 

setcap cap_net_raw,cap_net_admin+p /usr/bin/ping
Copy to Clipboard Toggle word wrap

Further, if a capability is provided by default in Docker, you do not need to modify the pod specification to request it. For example, NET_RAW is provided by default and capabilities should already be set on ping, therefore no special steps should be required to run ping.

To provide additional capabilities:

  1. Create a new SCC
  2. Add the allowed capability using the allowedCapabilities field.
  3. When creating the pod, request the capability in the securityContext.capabilities.add field.

7.8.7. Modify Cluster Default Behavior
リンクのコピー

To modify your cluster so that it does not pre-allocate UIDs, allows containers to run as any user, and prevents privileged containers:

Note

In order to preserve customized SCCs during upgrades, do not edit settings on the default SCCs other than priority, users, groups, labels, and annotations.

  1. Edit the restricted SCC: 

     $ oc edit scc restricted
    Copy to Clipboard Toggle word wrap
  2. Change runAsUser.Type to RunAsAny.
  3. Ensure allowPrivilegedContainer is set to false.
  4. Save the changes.

To modify your cluster so that it does not pre-allocate UIDs and does not allow containers to run as root:

  1. Edit the restricted SCC: 

     $ oc edit scc restricted
    Copy to Clipboard Toggle word wrap
  2. Change runAsUser.Type to MustRunAsNonRoot.
  3. Save the changes.

7.8.8. Use the hostPath Volume Plug-in
リンクのコピー

To relax the security in your cluster so that pods are allowed to use the hostPath volume plug-in without granting everyone access to the privileged SCC:

  1. Edit the restricted SCC: 

    $ oc edit scc restricted
    Copy to Clipboard Toggle word wrap
  2. Add allowHostDirVolumePlugin: true.
  3. Save the changes.

7.8.9. Ensure That Admission Attempts to Use a Specific SCC First
リンクのコピー

You may control the sort ordering of SCCs in admission by setting the Priority field of the SCCs. Please see the SCC Prioritization section for more information on sorting.

7.8.10. Add an SCC to a User or Group
リンクのコピー

To add an SCC to a user: 

$ oadm policy add-scc-to-user <scc_name> <user_name>
Copy to Clipboard Toggle word wrap

To add an SCC to a service account: 

$ oadm policy add-scc-to-user <scc_name>  \
    system:serviceaccount:<serviceaccount_namespace>:<serviceaccount_name>
Copy to Clipboard Toggle word wrap

To add an SCC to a group: 

$ oadm policy add-scc-to-group <scc_name> <group_name>
Copy to Clipboard Toggle word wrap

To add an SCC to all service accounts in a namespace: 

$ oadm policy add-scc-to-group <scc_name>  \
    system:serviceaccounts:<serviceaccount_namespace>
Copy to Clipboard Toggle word wrap
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat