Interaction with OpenShift Online is associated with a user. An OpenShift Online user object represents an actor which may be granted permissions in the system by
Several types of users can exist:
This is the way most interactive OpenShift Online 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
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
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
Every user must authenticate in some way in order to access OpenShift Online.
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.
A Kubernetes namespace provides a mechanism to scope resources in a cluster. In OpenShift Online, 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.
The Kubernetes documentation has more information on namespaces.
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 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.
displayName is how the project is displayed in the web console (defaults to
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:
Pods, services, replication controllers, etc.
Rules for which users can or cannot perform actions on objects.
Quotas for each kind of object that can be limited.
Service accounts act automatically with designated access to objects in the project.
Cluster administrators can create projects and delegate administrative rights for the project to any member of the user community. Cluster administrators can also allow developers to create their own projects.
Developers and administrators can interact with projects using the CLI or the web console.
OpenShift Online comes with a number of projects out of the box, and projects
openshift- are the most essential to users.
These projects host master components that run as pods and other infrastructure
components. The pods created in these namespaces that have a
critical pod annotation
are considered critical, and they have guaranteed admission by kubelet.
Pods created for master components in these namespaces are already marked as
In OpenShift Online Starter, a project that is inactive for more than 24 hours
is idled. When a project’s network activity falls below a configured threshold,
a project is deemed inactive. When a project is idled, the replica count is set
0 and all pods are deleted. All persistent volumes (PVs) and persistent
volume claims (PVCs) in the project are left untouched. Upon receiving network
traffic, the replica count will be scaled back to whatever it was before being
In the web console, you will see your deployment as Idled due to inactivity and you can manually scale the deployment back up.
If network traffic does not restore a project’s replica counts, then you may have to manually scale up the deployment.
If your OpenShift Online Starter account is inactive, meaning that you have had no running pods in your project for 3 days, you will receive a warning email that your account is to be deprovisioned. If you do not take corrective action and create pods within 5 days, your account is automatically deprovisioned. Once your account is deprovisioned, you can register again.