Skip to main content
Hello, and welcome to this detailed lesson on managing projects and users in OpenShift. In this guide, you will gain a comprehensive understanding of how OpenShift organizes resources using projects and how it handles user management and authentication. This knowledge is invaluable for ensuring secure, isolated, and efficient operations within your OpenShift cluster.

​
Understanding Projects

Once your OpenShift cluster is up and running—with both UI and CLI access—you can start exploring its core concepts. OpenShift projects are essential for organizing and managing resources efficiently. They allow teams to work in isolation, even in a consolidated environment where resources are shared. Consider a large Kubernetes cluster handling hundreds of deployments, pods, and services. In such environments, multiple teams might inadvertently have resource conflicts or unwanted access to each other’s deployments. OpenShift projects mitigate these risks by grouping resources and enforcing isolation. Under the hood, projects in OpenShift are implemented as Kubernetes namespaces. When a project is created, Kubernetes automatically prefixes resource names for basic grouping, while OpenShift ensures full grouping and isolation in a seamless manner. Below is a diagram that illustrates how multiple projects are structured. In this image, each project contains a service called “teamX.myservice” connected to various components (shown as red cubes), with servers arranged in a row at the bottom.
The image is a diagram showing four projects, each with a service labeled "teamX.myservice" and connected to multiple components, represented by red cubes. Below, there are icons of servers arranged in a row.
Once a project is created, you can deploy applications without the hassle of manually managing namespaces—OpenShift automates these details to streamline your workflow.

​
User Management in OpenShift

OpenShift features robust user management capabilities by categorizing users into three primary types:
  1. Regular Users:
    These are everyday users such as developers who interact with the platform to deploy and maintain applications. An example of a regular user is the typical “developer” account.
  2. System Users:
    These are specialized accounts designated for managing the infrastructure. They include cluster administrators and node-specific users. By default, OpenShift creates several system accounts (e.g., “system:admin”, “system:master”). These accounts use a system: prefix to distinguish them from regular user accounts.
  3. Service Accounts:
    Service accounts are used within projects to enable secure communication between internal application components. For instance, a web server might use a service account to connect to a database. These accounts are automatically prefixed with system:serviceaccount.
Below is a code snippet showcasing example names of system and service accounts: 
system:admin
system:master
system:serviceaccount:proj1:db_user
The image below visually summarizes the three types of users. It features icons that represent a regular user (“developer”), a system user (“system:admin”), and a service account (illustrated by an Android robot).
The image shows three user types: "Regular" with a simple person icon, "System" with a female silhouette icon, and an Android robot icon, each labeled with roles like "developer" and "system:admin".
Understanding the differences between these user types is crucial for setting up proper access control and ensuring your cluster remains secure.

​
OAuth and User Authentication

OpenShift integrates an OAuth server directly into the Master, which governs user authentication and authorization. This approach simplifies login processes and secures access to your cluster. In simple deployments, such as when using Minishift in an all-in-one mode, OpenShift is configured with an “allow-all” identity provider. This means any user can log in using any password, and if a user doesn’t exist, OpenShift will automatically create the account on the first login. Note that in this configuration, the password is not actually validated. For more secure environments, the “deny-all” identity provider is the default. Here, no user can access the cluster unless an administrator explicitly creates and enables their account. If you need to modify these settings, you can update the master configuration at /etc/openshift/master/master-config.yaml. The following diagram outlines the behavior of the OAuth server for both “Allow All” and “Deny All” configurations. It also highlights the location of the master configuration file.
The image shows a diagram related to an OAuth Server with icons representing "Allow All" and "Deny All" configurations, along with a file path: /etc/openshift/master/master-config.yaml.
In production environments, always opt for a secure identity provider configuration to prevent unauthorized access.

​
Conclusion

This lesson has provided you with a thorough introduction to projects and user management in OpenShift. You learned how projects facilitate isolated deployments through Kubernetes namespaces and how OpenShift’s intuitive grouping and access controls simplify resource management. Additionally, the lesson clarified the distinctions between regular users, system users, and service accounts, as well as reviewed the OAuth server configurations that secure your cluster. Thank you for joining this lesson. For further reading and more detailed instructions, please consult the OpenShift Documentation. See you in the next lesson!

Watch Video