Skip to main content
Welcome — in this lesson we’ll explore OpenShift projects and users, and how they map to Kubernetes primitives to provide isolation, access control, and easier multi-team operations. With a working OpenShift cluster and access to the UI and CLI, it’s important to understand how projects and user identities are modeled and enforced. This knowledge helps teams safely share cluster resources while avoiding naming collisions, accidental interference, and privilege overreach.

​
Why projects matter

A large Kubernetes/OpenShift cluster often hosts hundreds of deployments and services for multiple teams. Without logical boundaries:
  • There are no built-in restrictions on who can access which resources.
  • Teams must coordinate names because resource names must be unique within the same scope.
  • Accidental resource interference and privilege overreach become more likely.
OpenShift solves these problems by providing projects — a user-friendly layer on top of Kubernetes namespaces that groups and isolates resources and simplifies access management.

​
Projects vs Namespaces

Under the hood, OpenShift projects are implemented using Kubernetes namespaces. Namespaces scope resources so that the same object name can exist in different namespaces while remaining isolated. From a user perspective:
  • You create a project, deploy your application, and OpenShift handles the underlying namespace management.
  • Projects add OpenShift-specific features and access controls (RBAC bindings, default resource limits, project templates, etc.) that make team workflows simpler.
A presentation slide titled "Projects" showing four rounded team/service panels (Service: team1.myservice to team4.myservice) with user icons, container/cube icons and connection links. Below the panels is a long row of red server icons.

​
User types in OpenShift

OpenShift distinguishes between several kinds of users. Understanding these is essential for designing secure authentication and authorization: Example service account username format:
OpenShift masters include a built-in OAuth server that handles authentication; authorization is then enforced via Kubernetes/OpenShift RBAC (Roles, ClusterRoles, RoleBindings, ClusterRoleBindings) and other policies.

​
Identity providers and OAuth

The configured identity provider(s) determine how users are authenticated. OpenShift supports multiple identity provider types (LDAP, GitHub, OpenID Connect, etc.), and the behavior depends on your configuration:
  • Allow-all / local development: In single-node or development setups (e.g., Minishift), the AllowAllIdentityProvider lets any username/password combination log in and automatically creates the user the first time. This is convenient for demos and testing but insecure for production.
  • Deny-all / locked-down installs: The DenyAllIdentityProvider rejects all logins until an administrator explicitly creates and enables users or configures a proper identity provider.
To change OAuth and identity provider configuration, edit the master configuration. On many OpenShift 3.x systems the master config lives at:
A presentation slide titled "OAuth Server" shows a single red server icon labeled "Allow All" and a cluster of red server icons labeled "Deny All." A red compass-like logo and the title appear at the top left.
For local development (Minishift) the AllowAllIdentityProvider is convenient but insecure. Configure a production-grade identity provider (LDAP, OAuth/OIDC, SAML, etc.) before using a cluster for real workloads.

​
Practical tips

  • Use projects to separate environments (dev, test, prod) or teams to prevent naming collisions and accidental interference.
  • Apply RBAC at the project level to grant least privilege to users and service accounts.
  • Use service accounts for in-cluster applications; never embed cluster credentials in application code.
  • For production, integrate with a centralized identity provider (LDAP, OIDC) and enforce multi-factor authentication where possible.

​
References

Let’s head over to the demo to see projects and users in action. That’s it for this lesson.

Watch Video