OpenShift Security Concepts

Internal

• OpenShift Concepts

User

https://docs.openshift.com/container-platform/latest/architecture/core_concepts/projects_and_users.html

https://docs.openshift.com/container-platform/latest/rest_api/openshift_v1.html#read-the-specified-user

Interaction with OpenShift is associated with a user. An OpenShift user is an entity that can make requests to the OpenShift API. Typically, an user represents the account of a developer or administrator. The users are internally represented with an User object, which in turn represents an actor. Permissions can be given to actors in the system by adding roles to them, or their groups. The association between an user or group and a role is called binding. A user/group may be bound to multiple roles.

There are several user types:

Regular User

An individual system user. Regular users are created automatically upon the first login, or they can be created with the API. They are represented with the User object.

System User

Most system users are created automatically when the infrastructure is defined, for the purpose of enabling the infrastructure to interact with the API securely. System users include:

• The cluster administrator (system:admin). The cluster administrator has access to everything.

__Template:System:admin__

Template:System:admin is the cluster administrator. It uses certificate to authenticate with the environment. The certificate is stored in Template:~/.kube/config file under the Unix account used to connect to the OpenShift environment, usually root, in the "users:" section. The original content of Template:~/.kube/config for the Unix root account of the master server is created by copying it from Template:/etc/openshift/master/admin.kubeconfig.

Also see [.kube/config|KubeConfig].

• A per-node user (system:node:node1.example.com).
• Users for use by routers.
• Users for use by registries (system:openshift-registry)
• An anonymous system user.

Service Account

Special system, non-human users that act automatically with designated access to objects in their projects or other projects. Typically used by services such as routers and registries, or when system components need to make an API call to the master. Service accounts are created automatically when a new project is created, and the content of "serviceAccountConfig/managedNames" in the master configuration file specify what service accounts to be created. By default, "builder", "deployer" and "default" are created for all projects. Service accounts provide a way to control API access without sharing regular user credentials. Service account authenticated to the API using tokens signed by an internal private RSA key, which is verified by the authentication layer. Service accounts can be granted roles like a regular user, using oc policy add-role-to-user command. Every service account is member of the groups "system:service accounts" and "system:serviceaccounts:<project>" and it is given the "system:image-puller" role. The service accounts are represented with the ServiceAccount object. Examples: "system:service account:default:deployer".

Relationship between Users, Groups, Bindings, Roles and Rules

Policy

Policies

Authentication

https://docs.openshift.com/container-platform/latest/architecture/additional_concepts/authentication.html

https://docs.openshift.com/container-platform/latest/admin_solutions/authentication.html

The authentication layer provides a framework for collaboration and quota management. It supports multiple mechanisms for authentication. API calls are authenticated with a token issued by the authentication mechanism. The authentication is performed with oc login.

Security Context Constraints

https://docs.openshift.com/container-platform/latest/architecture/additional_concepts/authorization.html#security-context-constraints

OpenShift uses Security Context Constraints (SCCs) to control the actions that a pod can perform and what it has the ability to access.