$ oc policy scc-review -z system:serviceaccount:projectname:default -f my_resource.yaml
Azure Red Hat OpenShift 3.11 will be retired 30 June 2022. Support for creation of new Azure Red Hat OpenShift 3.11 clusters continues through 30 November 2020. Following retirement, remaining Azure Red Hat OpenShift 3.11 clusters will be shut down to prevent security vulnerabilities.
Follow this guide to create an Azure Red Hat OpenShift 4 cluster. If you have specific questions, please contact us
This topic contains authorization tasks for application developers and their capabilities, as dictated by the cluster administrator.
Using the scc-review
and scc-subject-review
options, you can see if an
individual user, or a user under a specific service account, can create or
update a pod.
Using the scc-review
option, you can check if a service account can create or
update a pod. The command outputs the security context constraints that admit
the resource.
For example, to check if a user with the
system:serviceaccount:projectname:default
service account can a create a pod:
$ oc policy scc-review -z system:serviceaccount:projectname:default -f my_resource.yaml
You can also use the scc-subject-review
option to check whether a specific
user can create or update a pod:
$ oc policy scc-subject-review -u <username> -f my_resource.yaml
To check if a user belonging to a specific group can create a pod in a specific file:
$ oc policy scc-subject-review -u <username> -g <groupname> -f my_resource.yaml
From within your Azure Red Hat OpenShift project, you can determine what verbs you can perform against all namespace-scoped resources (including third-party resources).
The can-i
command option tests scopes in terms of the user and role.
$ oc policy can-i --list --loglevel=8
The output helps you to determine what API request to make to gather the information.
To receive information back in a user-readable format, run:
$ oc policy can-i --list
The output provides a full list.
To determine if you can perform specific verbs, run:
$ oc policy can-i <verb> <resource>
can provide more information about a given scope. For example:
$ oc policy can-i <verb> <resource> --scopes=user:info