Authentication and authorization

Concepts: Authentication vs Authorization in OpenShift

OpenShift separates two closely related concerns:

• Authentication: Who are you? (Verifying identity)
• Authorization: What are you allowed to do? (Checking permissions)

Every request to the OpenShift API (via oc, web console, other tools) first goes through:

1. Authentication → request gets a user identity.
2. Authorization → access is allowed or denied based on that identity.

You will see this flow whenever you log in to the web console or use oc login.

Authentication in OpenShift

OpenShift does not manage accounts directly (like a traditional Unix /etc/passwd); it integrates with external identity providers and issues tokens.

Users, Identities, and Service Accounts

At the authentication layer, OpenShift deals with:

• User: An OpenShift user object (e.g. alice).
• Identity: How that user is known at an external identity provider. For example:
• github:alice-gh
• ldap:uid=alice,ou=People,dc=example,dc=com
• ServiceAccount: A special type of user for applications, not humans.

Mappings:

• An identity from a provider is linked to exactly one user in OpenShift.
• A user can be linked to multiple identities (e.g. LDAP and GitHub).

Service accounts:

• Are scoped to a project/namespace (e.g. system:serviceaccount:myproj:builder).
• Are authenticated using service account tokens, usually mounted as a file inside a pod.

Authentication Methods

OpenShift supports multiple authentication methods through identity providers. Typical ones:

• OAuth with web-based login:
• When you access the web console, you usually go through the OpenShift OAuth server.
• You may see a login form (local users) or be redirected to an external provider (e.g. corporate SSO).
• Token-based login:
• Using oc login --token=... --server=....
• Tokens are typically OAuth access tokens issued after authentication.
• Service Account Tokens:
• Pods typically authenticate to the API server using a token from a mounted file, e.g.:
• /var/run/secrets/kubernetes.io/serviceaccount/token
• CLI interactive login:
• oc login https://api.example.com:6443
• You might be prompted for username/password, or a browser-based login may open, depending on configuration.

Identity Providers (IdPs)

Identity providers are configured at the cluster level. Common options include:

• LDAP
• Active Directory
• GitHub / GitLab / OAuth2 providers
• HTPasswd (simple file-based users; often in labs/demos)
• OpenID Connect / SAML (enterprise SSO)

Conceptually, each IdP:

1. Verifies the user’s credentials (password, SSO token, etc.).
2. Returns identity data (username, groups, email).
3. OpenShift maps this identity to a user object and issues an access token.

As a regular user, you mainly need to know:

• Which authentication method your cluster uses (SSO, username/password, token).
• How to obtain a token if you need one (for scripts, automation, etc.).

The OAuth Server and Tokens

OpenShift uses an internal OAuth server for authentication:

• Issues access tokens after successful authentication.
• Optionally issues refresh tokens (depending on config).
• Can be used for:
• Web console sessions.
• oc CLI tokens.
• Third-party tools that call the OpenShift API.

You can typically:

• See who you are logged in as:
• oc whoami
• See your groups:
• oc whoami --show-groups
• View the API URL and context:
• oc config view

Tokens should be treated as sensitive credentials:

• Don’t commit them to Git.
• Don’t share them.
• Rotate/revoke them if compromised.

Authorization in OpenShift

Authorization decides whether an authenticated user or service account can perform an action (verb) on a resource.

Examples:

• Can user alice create pods in project dev?
• Can the builder service account read image streams?
• Can a CI user list all projects?

OpenShift mainly uses Kubernetes RBAC, with some OpenShift-specific roles and resources.

Basic Authorization Model

Every request is evaluated as:

• Subject: a user or service account (and its groups).
• Action:
• Verb: get, list, create, update, delete, patch, watch
• Resource: pods, deployments, routes, secrets, etc.
• Namespace/project (if namespaced).
• The RBAC engine checks if there is a RoleBinding or ClusterRoleBinding that grants the permission.

If there is a grant → request allowed, otherwise → denied.

Roles and RoleBindings

Authorization is managed through Roles and Bindings:

• Role:
• A collection of rules (permissions) scoped to a namespace.
• ClusterRole:
• Similar but cluster-wide; can grant namespaced or cluster-level permissions.
• RoleBinding:
• Binds a Role to users/groups/service accounts in a specific namespace.
• ClusterRoleBinding:
• Binds a ClusterRole cluster-wide, possibly affecting many or all namespaces.

Example pattern:

• Define what: edit rights to modify objects in a project.
• Bind it to who: alice in the dev project.

Conceptually:

• Role / ClusterRole = “permissions template”
• RoleBinding / ClusterRoleBinding = “who gets which template, and where”

Common Built-in Roles

Typical built-in ClusterRoles you will encounter:

• cluster-admin
• Full control over the entire cluster.
• admin
• Full control over a project/namespace; can manage roles within it.
• edit
• Can create, modify most resources in a project, but not manage RBAC.
• view
• Read-only access to most resources in a project.

OpenShift adds some specialized roles, for example:

• system:deployer, system:image-builder, etc., used by internal components.

As a developer or basic user you will mostly be assigned:

• view, edit, or admin roles at the project level.

Checking and Understanding Your Permissions

OpenShift provides CLI tools to inspect and troubleshoot authorization:

• See your current user:
• oc whoami
• See your groups:
• oc whoami --show-groups
• Check if you can perform an action:
• oc auth can-i get pods
• oc auth can-i delete pods -n other-project
• oc auth can-i ' ' --all-namespaces (requires appropriate privileges to answer)
• List roles in a project:
• oc get roles
• oc get rolebindings
• List cluster roles:
• oc get clusterroles
• oc get clusterrolebindings

Typically:

• If a command fails with “forbidden” and you suspect a permissions issue, try:
• oc auth can-i <verb> <resource> -n <namespace>
• If you are a project admin, you can inspect and adjust role bindings in your project.

Project Membership and Access

Projects (namespaces) use RBAC for membership and access:

• Common pattern:
• A user (like a project owner) is bound to admin for that project.
• Additional users:
• edit → developers who can change resources.
• view → stakeholders or tools that need read-only access.
• In many setups, groups (from your IdP) are bound to roles, e.g.:
• Group dev-team-a gets edit on project team-a-dev.
• Group ops-team gets view or admin across many projects.

This means:

• Your ability to see a project in the web console or via oc get projects often depends on whether you have at least view in that project.
• Losing a role binding can make a project “disappear” from your view even if the project still exists.

Service Accounts and Application Permissions

Service accounts are central to how applications access the API and other resources.

Key points:

• Every namespace has default service accounts (e.g. default, builder, deployer).
• When you create a pod or deployment, it runs under a specific service account:
• Explicitly set via spec.serviceAccountName.
• Or the namespace’s default if not specified.
• That service account’s permissions (via RoleBindings/ClusterRoleBindings) define:
• Whether the pod can read ConfigMaps, Secrets, or talk to the API server.
• Whether it can create or modify other resources.

For secure applications:

• Use dedicated service accounts with minimal privileges.
• Bind roles only with the necessary permissions (principle of least privilege).
• Avoid using overly privileged service accounts like one with admin unless absolutely required.

Labels, Groups, and External Identity

Authorization often leverages groups:

• Groups may be:
• Defined by the identity provider (e.g. LDAP group).
• Created manually in OpenShift and populated with users.
• Permissions are usually assigned to groups, not individual users, for easier management:
• Example:
• Group app-devs is bound to edit on a set of projects.
• HR or IT manages actual membership in app-devs via AD/LDAP.

This decouples:

• Identity management (in IdP) from
• Authorization policies (in OpenShift RBAC).

Security Considerations and Good Practices

Even at an introductory level, keep in mind:

• Protect credentials and tokens:
• Treat oc login tokens and service account tokens like passwords.
• Use least privilege:
• Request view when you only need read access.
• Avoid cluster-admin for day-to-day work.
• Separate human and automation identities:
• Use dedicated service accounts for automation (CI pipelines, bots).
• Understand scope:
• A Role and RoleBinding are namespace-scoped; ClusterRole and ClusterRoleBinding can affect the whole cluster.
• Audit and review:
• Periodically review which roles and bindings exist in your projects.

Practical CLI Examples (Conceptual)

You will use these types of commands in hands-on work:

• Log in:
• oc login https://api.example.com:6443
• Check identity:
• oc whoami
• oc whoami --show-groups
• Check capabilities:
• oc auth can-i create pods -n myproject
• See who has access in a project:
• oc get rolebindings -n myproject
• oc describe rolebinding <name> -n myproject

The exact outputs and available roles depend on how your cluster is configured and which roles your administrators have defined.