oc Auth Can I Security Examples¶

Introduction¶

RBAC decides which OpenShift users and service accounts can act on resources. oc auth can-i is the quickest safe test before changing RoleBindings.

Why This Matters¶

OpenShift adds security defaults such as SCCs, project isolation, and integrated OAuth/RBAC behavior. These protections are useful only when permissions are granted narrowly and verified.

Step-by-Step Configuration¶

oc auth can-i get pods -n app

oc auth can-i create routes -n app --as=developer

oc get rolebinding -n app

oc describe rolebinding edit-developer -n app

Example output:

yes
no

Example YAML¶

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: edit-developer
  namespace: app
subjects:
  - kind: User
    name: developer
roleRef:
  kind: ClusterRole
  name: edit
  apiGroup: rbac.authorization.k8s.io

Verification¶

oc auth can-i get pods -n app --as=developer

oc get rolebinding -n app

oc describe rolebinding edit-developer -n app

Security Best Practices¶

Grant the smallest role or SCC that works, prefer service-account-specific access, keep secrets out of Git, and verify permissions with oc auth can-i.

Common Mistakes¶

• Granting cluster-admin for a namespace-scoped problem.
• Testing permissions as yourself instead of the affected service account.
• Forgetting that SCC use is also authorized through RBAC.

Troubleshooting¶

Compare the failing user or service account with the role binding, SCC admission error, project quota, or OAuth status shown in OpenShift events.

Related Guides¶

• Openshift Security Context Constraints Explained
• Openshift RBAC Security Explained
• Openshift Security Checklist

Summary¶

oc Auth Can I Security Examples is safest when permissions are explicit, namespace-scoped where possible, and validated from the same identity that runs the workload.