This is a cache of https://docs.okd.io/3.9/dev_guide/authorization.html. It is a snapshot of the page at 2024-11-25T04:13:41.009+0000.
Authorization | Developer Guide | OKD 3.9
×

Overview

This topic contains authorization tasks for application developers and their capabilities, as dictated by the cluster administrator.

Checking If Users Can Create Pods

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

Determining What You Can Do as an Authenticated User

From within your OKD 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>

User scopes can provide more information about a given scope. For example:

$ oc policy can-i <verb> <resource> --scopes=user:info