OpenShift Security Concepts: Difference between revisions
(→Secret) |
No edit summary |
||
| Line 136: | Line 136: | ||
An OAuth client. | An OAuth client. | ||
Revision as of 18:00, 12 October 2017
External
Internal
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. The regular users on the system can be obtained as "system:admin" with oc get users.
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:
Cluster Administrator
The cluster administrator 'system:admin'. The cluster administrator has access to everything. It uses a certificate to authenticate with the environment. The certificate is stored in ~/.kube/config file under the Unix account used to connect to the OpenShift environment, in the "users:" section. The original content of ~/.kube/config for the Unix root account of the master server is created by copying it from /etc/origin/master/admin.kubeconfig. This is the procedure allow system:admin to access a remote environment via oc:
Additional users can be made cluster administrators, by ....
To list the cluster administrators:
oc get clusterrolebinding/cluster-admins
Per-Node System User
A per-node user 'system:node:node1.example.com'.
Other System Users
- Users for use by routers.
- Users for use by registries 'system:openshift-registry'
Anonymous System User
An anonymous system user.
Service Account
A service account is a special, non-human system user that acts 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".
The service accounts for a project can be obtained with oc get sa.
A new service account can be created with oc create.
Service accounts and secrets: What is the relationship between service accounts and secrets. What is the semantics of adding a secret to a service account?
User Identity
Information about the identity of users can be obtained with oc get identity. Users are uniquely identified on the system by their UID, but they can have multiple user names associated with them, if they come into the system after being authenticated by different identity providers.
oc get identity NAME IDP NAME IDP USER NAME USER NAME USER UID allow_all:alice allow_all alice alice 2c381dd3-5bbe-11e5-9ccb-08002733d9bd htpasswd:alice htpasswd alice alice2 b19b75ba-5bce-11e5-b065-08002733d9bd
An identity can be deleted with oc delete identity.
User Context
Returned by oc whoami -c.
Group
A group is a set of users. A user can be part of multiple groups. Groups are useful when we want to grant permissions to multiple users at once, versus granting the same permissions to users individually. Groups can be explicitly defined or they can be system groups (virtual groups) that are automatically provisioned by OpenShift.
A group can be associated with multiple roles by binding it to the roles.
Group information can be obtained with oc describe group. A new group can be created with oadm groups.
Virtual Group
system:authenticated - automatically associated with any currently-authenticated users.
system:unauthenticated - automatically associated with any currently-unauthenticated users.
Binding
Role
Rule
Relationship between Users, Groups, Bindings, Roles and Rules
Policy
Authentication
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.
TODO: https://home.feodorov.com:9443/wiki/Wiki.jsp?page=OpenShiftAuthentication
Authentication Methods
Identity Providers
Authorization
TODO: https://home.feodorov.com:9443/wiki/Wiki.jsp?page=OpenShiftAuthorization
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.
Secret
A secret.
OAuthClient
An OAuth client.