Projects and Users

Users

Interaction with OpenShift Container Platform is associated with a user. An OpenShift Container Platform
user object represents an actor which may be granted permissions in the system
by
adding
roles to them or to their groups.

Several types of users can exist:

Regular users

This is the way most interactive OpenShift Container Platform users will be
represented. Regular users are created automatically in the system upon
first login, or can be created via the API. Regular users are represented
with the User object. Examples: joealice

System users

Many of these are created automatically when the infrastructure
is defined, mainly for the purpose of enabling the infrastructure to
interact with the API securely. They include a cluster administrator
(with access to everything), a per-node user, users for use by routers
and registries, and various others. Finally, there is an anonymous
system user that is used by default for unauthenticated requests. Examples:
system:adminsystem:openshift-registrysystem:node:node1.example.com

Service accounts

These are special system users associated with projects; some are created automatically when
the project is first created, while project administrators can create more
for the purpose of defining access to the contents of each project.
Service accounts are represented with the ServiceAccount object. Examples:
system:serviceaccount:default:deployersystem:serviceaccount:foo:builder

Every user must authenticate in some way in order to access OpenShift Container Platform.
API requests with no authentication or invalid authentication are authenticated as requests by the anonymous system user.
Once authenticated, policy determines what the user is authorized to do.

Namespaces

A Kubernetes namespace provides a mechanism to scope resources in a cluster.
In OpenShift Container Platform, a project is a Kubernetes namespace with
additional annotations.

Namespaces provide a unique scope for:

Named resources to avoid basic naming collisions.

Delegated management authority to trusted users.

The ability to limit community resource consumption.

Most objects in the system are scoped by namespace, but some are
excepted and have no namespace, including nodes and users.

Projects

A project is a Kubernetes namespace with additional annotations, and is the central vehicle
by which access to resources for regular users is managed.
A project allows a community of users to organize and manage their content in
isolation from other communities. Users must be given access to projects by administrators,
or if allowed to create projects, automatically have access to their own projects.

Projects can have a separate name, displayName, and description.

The mandatory name is a unique identifier for the project and is most visible when using the CLI tools or API. The maximum name length is 63 characters.

The optional displayName is how the project is displayed in the web console (defaults to name).

The optional description can be a more detailed description of the project and is also visible in the web console.

Each project scopes its own set of:

Objects

Pods, services, replication controllers, etc.

Policies

Rules for which users can or cannot perform actions on objects.

Constraints

Quotas for each kind of object that can be limited.

Service accounts

Service accounts act automatically with designated access to objects in the project.

Projects provided at installation

OpenShift Container Platform comes with a number of projects out of the box, and openshift is the most essential to users:

openshift
A user-facing project, mainly for housing objects for day-to-day tasks. These
include any application objects for access by multiple projects, such as
templates and images. These objects should be those that do not require
communication between the pods.