OpenShift Security Concepts: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
 
(58 intermediate revisions by the same user not shown)
Line 4: Line 4:
* https://docs.openshift.com/container-platform/latest/architecture/additional_concepts/authentication.html
* https://docs.openshift.com/container-platform/latest/architecture/additional_concepts/authentication.html
* https://docs.openshift.com/container-platform/latest/architecture/additional_concepts/authorization.html
* https://docs.openshift.com/container-platform/latest/architecture/additional_concepts/authorization.html
* https://opensource.com/business/14/7/docker-security-selinux
* https://www.openshift.com/blog/a-guide-to-openshift-and-uids


=Internal=
=Internal=
Line 28: Line 30:
====Cluster Administrator====
====Cluster Administrator====


<span id='The_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 [[Admin.kubeconfig|/etc/origin/master/admin.kubeconfig]]. This is the procedure allow system:admin to access a remote environment via [[oc]]:
<span id='The_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|.kube/config]] file under the Unix account used to connect to the OpenShift environment, in the "users:" section. The original content of ~/[[.kube config|.kube/config]] for the Unix root account of the master server is created by copying it from [[Admin.kubeconfig|/etc/origin/master/admin.kubeconfig]]. This is the procedure allow system:admin to access a remote environment via [[oc]]:


{{Internal|OpenShift Enable system:admin Remote Access|Procedure to enable system:admin remote access}}
{{Internal|OpenShift Enable system:admin Remote Access|Procedure to enable system:admin remote access}}
Line 50: Line 52:


==Service Account==
==Service Account==
{{External|https://docs.openshift.com/container-platform/latest/dev_guide/service_accounts.html}}


A ''service account'' is a special, non-human [[#System_User|system user]] that acts automatically and requires access to objects in its own project or other projects. Service accounts are associated with projects (namespace-scoped).  
A ''service account'' is a special, non-human [[#System_User|system user]] that acts automatically and requires access to objects in its own project or other projects. Service accounts are associated with projects (namespace-scoped).  


Service accounts are typically used by services such as routers and registries, or when system components need to make an API call to the master: for example, when replication controllers make API calls to create or delete pods, when [[Jenkins_and_OpenShift#Security_Considerations|Jenkins interacts with the master to start a build]], or when an external application makes API calls for monitoring and integration purposes.  
Service accounts are typically used by services such as routers and registries, or when system components need to make an API call to the master: for example, when replication controllers make API calls to create or delete pods, when [[OpenShift CI/CD Concepts#Security_Considerations|Jenkins interacts with the master to start a build]], or when an external application makes API calls for monitoring and integration purposes. The reason to use service account in all these cases is that they provide a way to control API access without sharing [[#Regular_User|regular user]] credentials. Service account authenticated to the API using tokens signed by an internal private RSA key, which is verified by the [[OpenShift Concepts#Authentication_Layer|authentication layer]].
 
A number of service accounts are created automatically when the project is created. The list of service accounts to be created automatically is specified in the [[Master-config.yml#serviceAccountConfig|serviceAccountConfig/managedNames]] section of the OpenShift [[Master-config.yml|master configuration file]]. The list contains "builder", "deployer" and "default". When instantiated for a specific project, the service account specified in the master file become "system:serviceaccount:<''project-name''>:default", "[[OpenShift_Concepts#Build|system:serviceaccount:<''project-name''>:builder]]" and "system:serviceaccount:<''project-name''>:deployer", Additional service accounts can also be created by the project administrator, later.
 
Service accounts can be granted roles, in a same way a [[#Regular_User|regular user]] can be granted roles, using [[oc policy#add-role-to-user|oc policy add-role-to-user]] command. Every service account is member of the groups "system:serviceaccounts" and "system:serviceaccounts:<''project-name''>" and it is given the "system:image-puller" role.
 
Internally, the service accounts are represented with the <tt>ServiceAccount</tt> object.


A number of service accounts are created automatically when the project is created. The list of service accounts to be created automatically is specified in the [[Master-config.yml#serviceAccountConfig|serviceAccountConfig/managedNames]] section of the OpenShift [[Master-config.yml|master configuration file]]. The list contains "builder", "deployer" and "default". Additional service accounts can also be created by the project administrator, later.
Service accounts are specified in the deployment configuration as follows:


apiVersion: v1
kind: '''DeploymentConfig'''
'''spec''':
  ...
  '''template''':
    '''spec''':
      containers:
        ...
      '''serviceAccountName''': some-service-account




The list of service accounts for a project can be obtained with:


Service accounts provide a way to control API access without sharing [[#Regular_User|regular user]] credentials. Service account authenticated to the API using tokens signed by an internal private RSA key, which is verified by the [[OpenShift Concepts#Authentication_Layer|authentication layer]]. Service accounts can be granted roles like a [[#Regular_User|regular user]], using [[oc policy#add-role-to-user|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 <tt>ServiceAccount</tt> object. Examples: "system:service account:default:deployer" or "system:service account:some-project:builder"
[[OpenShift_Security_Operations#Query_Service_Accounts_for_a_Project|oc get sa]]


The service accounts for a project can be obtained with [[OpenShift_Security_Operations#Query_Service_Accounts_for_a_Project|oc get sa]] and can be created with [[OpenShift_Security_Operations#Create_a_New_Service_Account|oc create]].
and can be created with  


<font color=red>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?</font>
[[OpenShift_Security_Operations#Create_a_New_Service_Account|oc create]]
 
===Service Accounts and Secrets===
 
Service accounts are associated with secrets. The list of secrets associated with a service account can be obtained with oc sa as describe below:
 
{{Internal|OpenShift_Security_Operations#List_the_Secrets_associated_with_a_Service_Account|List the Secrets Associated with a Service Account}}
 
<font color=red>Service accounts link to secrets. What is the semantics of adding a secret to a service account?</font>
 
===Service Accounts and SCCs===
 
See: {{Internal|OpenShift_Security_Context_Constraints#Security_Context_Constraints_and_Service_Accounts|Service Accounts and SCCs}}


=User Identity=
=User Identity=
Line 97: Line 129:
system:unauthenticated - automatically associated with any currently-unauthenticated users.
system:unauthenticated - automatically associated with any currently-unauthenticated users.


=Binding=
=Role Binding=
<span id='Binding'></span>


The association between an user or group and a role is called ''binding''.
The association between an user or group and a role is called ''binding''.
Line 104: Line 137:


  [[OpenShift_Security_Operations#List_All_Cluster_Role_Bindings|oc get clusterrolebinding]]
  [[OpenShift_Security_Operations#List_All_Cluster_Role_Bindings|oc get clusterrolebinding]]
{{Internal|OpenShift RoleBinding Definition|RoleBinding Definition}}


=Role=
=Role=
Line 118: Line 153:
====/cluster-admin====
====/cluster-admin====
====/cluster-reader====
====/cluster-reader====
Allows:
* [[OpenShift_Concepts#Image|listing images in the cluster]]


====/system:registry====
====/system:registry====
Line 130: Line 168:


A ''local role'' is a role scoped to a specific project. A local role is part of the project's [[#Local_Policy|local policy]].
A ''local role'' is a role scoped to a specific project. A local role is part of the project's [[#Local_Policy|local policy]].
====/admin====
Users in this role have the [[#.2Fedit|/edit]] role and they can change the project's membership.
====/edit====
Users in this role can create and edit most objects in the project, but can't change the project's membership.
====/system:deployer====
Users in this role can deploy within the project. Used by [[#Service_Account|service accounts]] for automated deployments.
====/system:image-builder====
Users in this role can build, [[#.2Fsystem:image-pusher|push]] and [[#.2Fsystem:image-puller|pull]] images within the project. Used by [[#Service_Account|service accounts]] that perform builds.
====/system:image-pusher====
====/system:image-puller====


=Rule=
=Rule=
Line 166: Line 224:


The OpenShift master runs a built-in [[#OpenShift_Master_OAuth_Server|OAuth server]]. Users attempting to access the API via CLI or web console must authenticate and obtain an OAuth access token.
The OpenShift master runs a built-in [[#OpenShift_Master_OAuth_Server|OAuth server]]. Users attempting to access the API via CLI or web console must authenticate and obtain an OAuth access token.
Once authenticated, the bearer token can be obtained on command line with:
[[Oc_whoami#Obtaining_the_OAuth_Token|oc whoami -t]]


The OAuth server can be configured with a pluggable [[#Identity_Providers|identity provider]].
The OAuth server can be configured with a pluggable [[#Identity_Providers|identity provider]].
Line 183: Line 245:


<font color=red>TODO: https://home.feodorov.com:9443/wiki/Wiki.jsp?page=OpenShiftAuthorization</font>
<font color=red>TODO: https://home.feodorov.com:9443/wiki/Wiki.jsp?page=OpenShiftAuthorization</font>
=Security Context Constraints=
{{External|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.


=Secret=
=Secret=


A ''secret'' resource can hold text or binary secrets for delivery into pods. By default, every container is given a single secret which contains a token for accessing the API with limited privileges, at /var/run/secrets/kubernetes.io/serviceaccount. New secrets can be created and mounted into pods. Secrets from builds can be referenced.
{{Internal|OpenShift Secrets Concepts|Secrets Concepts}}
 
'Secret' operations: {{Internal|OpenShift_Security_Operations#.27Secret.27_Operations|'Secret' Operations}}


=OpenShift Master OAuth Server=
=OpenShift Master OAuth Server=
Line 203: Line 257:


The OAuth server configuration is specified in [[Master-config.yml#oauthConfig|/etc/origin/master/master-config.yaml]], under the "oauthConfig" label.
The OAuth server configuration is specified in [[Master-config.yml#oauthConfig|/etc/origin/master/master-config.yaml]], under the "oauthConfig" label.
===OAuth Token Duration===
{{External|https://docs.openshift.com/container-platform/4.5/authentication/configuring-internal-oauth.html#oauth-configuring-internal-oauth_configuring-internal-oauth}}


This is where the OAuth token expiration time can be specified:
This is where the OAuth token expiration time can be specified:


accessTokenMaxAgeSeconds: 86400
<syntaxhighlight lang='text'>
accessTokenMaxAgeSeconds: 86400
</syntaxhighlight>
 
Alternatively, it can be configured from the console: Administration → Cluster Settings → Global Settings → Oauth → Modify the Yaml configuration as follows:
 
<syntaxhighlight lang='text'>
apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  tokenConfig:
    accessTokenMaxAgeSeconds: 172800
</syntaxhighlight>
 
The confirmation can be obtained by running:
<syntaxhighlight lang='bash'>
oc describe oauth.config.openshift.io/cluster
</syntaxhighlight>


==OpenShift OAuth Authentication Sequence==
==OpenShift OAuth Authentication Sequence==
Line 229: Line 305:


OAuth client operations: {{Internal|OpenShift_Security_Operations#OAuth_Client_Operations|OAuth Client Operations}}
OAuth client operations: {{Internal|OpenShift_Security_Operations#OAuth_Client_Operations|OAuth Client Operations}}
=Certificates=
==Master (API Server) Certificate==
{{External|https://docs.openshift.com/container-platform/latest/install_config/certificate_customization.html}}
Configured in [[Master-config.yml#certFile|master-config.yaml]].
=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.
{{Internal|OpenShift Security Context Constraints|Security Context Constraints}}

Latest revision as of 01:10, 11 February 2021

External

Internal

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. 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:

Procedure to enable system:admin remote access

Additional users can be made cluster administrators executing oadm policy add-cluter-role-to-user command.

To list the cluster administrators, use oc get clusterrolebinding/cluster-admins command.

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. API requests with missing or invalid authentication are treated as requests from the anonymous system user.

Service Account

https://docs.openshift.com/container-platform/latest/dev_guide/service_accounts.html

A service account is a special, non-human system user that acts automatically and requires access to objects in its own project or other projects. Service accounts are associated with projects (namespace-scoped).

Service accounts are typically used by services such as routers and registries, or when system components need to make an API call to the master: for example, when replication controllers make API calls to create or delete pods, when Jenkins interacts with the master to start a build, or when an external application makes API calls for monitoring and integration purposes. The reason to use service account in all these cases is that they 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.

A number of service accounts are created automatically when the project is created. The list of service accounts to be created automatically is specified in the serviceAccountConfig/managedNames section of the OpenShift master configuration file. The list contains "builder", "deployer" and "default". When instantiated for a specific project, the service account specified in the master file become "system:serviceaccount:<project-name>:default", "system:serviceaccount:<project-name>:builder" and "system:serviceaccount:<project-name>:deployer", Additional service accounts can also be created by the project administrator, later.

Service accounts can be granted roles, in a same way a regular user can be granted roles, using oc policy add-role-to-user command. Every service account is member of the groups "system:serviceaccounts" and "system:serviceaccounts:<project-name>" and it is given the "system:image-puller" role.

Internally, the service accounts are represented with the ServiceAccount object.

Service accounts are specified in the deployment configuration as follows:

apiVersion: v1
kind: DeploymentConfig
spec:
  ...
  template:
    spec:
      containers:
        ...
      serviceAccountName: some-service-account


The list of service accounts for a project can be obtained with:

oc get sa

and can be created with

oc create

Service Accounts and Secrets

Service accounts are associated with secrets. The list of secrets associated with a service account can be obtained with oc sa as describe below:

List the Secrets Associated with a Service Account

Service accounts link to secrets. What is the semantics of adding a secret to a service account?

Service Accounts and SCCs

See:

Service Accounts and SCCs

User Identity

https://docs.openshift.com/container-platform/latest/architecture/additional_concepts/other_api_objects.html#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.

Role Binding

The association between an user or group and a role is called binding.

For a list of existing cluster role bindings, execute:

oc get clusterrolebinding
RoleBinding Definition

Role

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

Roles

Cluster Roles

A cluster role is a role applicable across all projects. A cluster role is part of the cluster policy.

/basic-user

/cluster-admin

/cluster-reader

Allows:

/system:registry

The role than needs to be bound to a service account so the service account can operate the integrated registry.

For a complete list of cluster roles, execute:

oc get clusterrolebinding

Local Roles

A local role is a role scoped to a specific project. A local role is part of the project's local policy.

/admin

Users in this role have the /edit role and they can change the project's membership.

/edit

Users in this role can create and edit most objects in the project, but can't change the project's membership.

/system:deployer

Users in this role can deploy within the project. Used by service accounts for automated deployments.

/system:image-builder

Users in this role can build, push and pull images within the project. Used by service accounts that perform builds.

/system:image-pusher

/system:image-puller

Rule

Relationship between Users, Groups, Bindings, Roles and Rules

OpenShiftSecurity.png

Policy

https://docs.openshift.com/container-platform/latest/architecture/additional_concepts/authorization.html#cluster-policy-and-local-policy

A policy is a collection of rules that specify which users can and cannot do with objects (pods, services, etc.). It is a Kubernetes concept.

Cluster Policy

The cluster policy contains roles and bindings that are applicable across all projects. Cluster bindings can only reference cluster roles.

Local Policy

The local policy contains roles and bindings that are scoped to a specific project. Local bindings can reference both cluster roles and local roles.

Authentication

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

An external user can interact with OpenShift only by making REST API calls. This is how command lines tools, web clients and everybody else interacts with it. Thus the process of authenticating against OpenShift is the process of authenticating against the REST API. Authentication means establishing the identity of the user making the API call. 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.

Authentication Methods

Requests to the OpenShift API are authenticated via two methods:

OAuth Access Tokens

The OpenShift master runs a built-in OAuth server. Users attempting to access the API via CLI or web console must authenticate and obtain an OAuth access token.

Once authenticated, the bearer token can be obtained on command line with:

oc whoami -t

The OAuth server can be configured with a pluggable identity provider.

X.509 Client Certificates

X.509

Identity Providers

Authorization

TODO: https://home.feodorov.com:9443/wiki/Wiki.jsp?page=OpenShiftAuthorization

Secret

Secrets Concepts

OpenShift Master OAuth Server

The master exposes an OAuth server at "/oauth/authorize".

OAuth Server Configuration

The OAuth server configuration is specified in /etc/origin/master/master-config.yaml, under the "oauthConfig" label.

OAuth Token Duration

https://docs.openshift.com/container-platform/4.5/authentication/configuring-internal-oauth.html#oauth-configuring-internal-oauth_configuring-internal-oauth

This is where the OAuth token expiration time can be specified:

accessTokenMaxAgeSeconds: 86400

Alternatively, it can be configured from the console: Administration → Cluster Settings → Global Settings → Oauth → Modify the Yaml configuration as follows:

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  tokenConfig:
    accessTokenMaxAgeSeconds: 172800

The confirmation can be obtained by running:

oc describe oauth.config.openshift.io/cluster

OpenShift OAuth Authentication Sequence

An OpenShift OAuth token request looks like this:

https://openshift-master1:8443/oauth/authorize?client_id=openshift-challenging-client&response_type=token

with a Basic Authorization header "Authorization: Basic b3ZpZGl1Om92aWRpdTEyMw=="

If authenticated, the response should be a 302 redirect with the Location that contains the token:

Location: https://openshift-master1:8443/oauth/token/display#access_token=Wvgp_89KM-OsOjfQb-wISSfxPFRJdfckAoFMBOrk7Qo&expires_in=86400&token_type=bearer

Note that https://openshift-master1:8443/oauth/token is not actually a redirect location, in that there's nothing there. Explain this.

For more details, see:

OpenShift OAuth Authentication Sequence

OAuthClient

An OAuth client.

OAuth client operations:

OAuth Client Operations

Certificates

Master (API Server) Certificate

https://docs.openshift.com/container-platform/latest/install_config/certificate_customization.html

Configured in master-config.yaml.

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.

Security Context Constraints