Authentication

For users to interact with OpenShift Container Platform, they must first authenticate to the cluster. The authentication layer identifies the user associated with requests to the OpenShift Container Platform API. The authorization layer then uses information about the requesting user to determine if the request is allowed. Understanding authentication | Authentication | OpenShift Container Platform

The OpenShift Container Platform includes a built-in OAuth server for token-based authentication. Developers and administrators obtain OAuth access tokens to authenticate themselves to the API. It is recommended for an administrator to configure OAuth to specify an identity provider after the cluster is installed. User access to the cluster is managed through the identity provider. Understanding identity provider configuration | Authentication | OpenShift Container Platform

OpenShift includes built-in role based access control (RBAC) to determine whether a user is allowed to perform a given action within the cluster. Roles can have cluster scope or local (i.e. project) scope. Using RBAC to define and apply permissions | Authentication | OpenShift Container Platform

You can configure OAuth tokens to expire after a set period of inactivity. By default, no token inactivity timeout is set.

The inactivity timeout can be either set in the OAuth server configuration or in any of the OAuth clients. The client settings override the OAuth server setting.

To set the OAuth server inactivity timeout, edit the OAuth server object: oc edit oauth cluster and set the .spec.tokenConfig.accessTokenInactivityTimeout parameter to the desired value:

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
...
spec:
   tokenConfig:
     accessTokenInactivityTimeout: 

Please note that the OAuth server converts the value internally to a human-readable format,
so that e.g. setting accessTokenInactivityTimeout=600s would be converted by the OAuth
server to accessTokenInactivityTimeout=10m0s.

You can configure OAuth tokens to expire after a set period of inactivity. By default, no token inactivity timeout is set.

The inactivity timeout can be either set in the OAuth server configuration or in any of the OAuth clients. The client settings override the OAuth server setting.

To set the OAuth server inactivity timeout, edit the OAuth server object: oc edit oauth cluster and set the .spec.tokenConfig.accessTokenInactivityTimeout parameter to the desired value:

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
...
spec:
   tokenConfig:
     accessTokenInactivityTimeout: 10m0s 
Please note that the OAuth server converts the value internally to a human-readable format,
so that e.g. setting accessTokenInactivityTimeout=600s would be converted by the OAuth
server to accessTokenInactivityTimeout=10m0s.

To edit the OAuth client inactivity timeout, edit the OAuth client object: oc edit oauthclient $clientname and set the top-level accessTokenInactivityTimeoutSeconds attribute.

apiVersion: oauth.openshift.io/v1
grantMethod: auto
kind: OAuthClient
metadata:
...
accessTokenInactivityTimeoutSeconds: 600 

You can configure OAuth tokens to have have a custom duration. By default, the tokens are valid for 24 hours (86400 seconds).

The maximum age can be either set in the OAuth server configuration or in any of the OAuth clients. The client settings override the OAuth server setting.

To set the OAuth server token max age, edit the OAuth server object: oc edit oauth cluster and set the .spec.tokenConfig.accessTokenMaxAgeSeconds parameter to the desired value:

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
...
spec:
   tokenConfig:
     accessTokenMaxAgeSeconds: 28800

To set the OAuth client token max age, edit the OAuth client object: oc edit oauthclient $clientname and set the top-level accessTokenMaxAgeSeconds attribute.

apiVersion: oauth.openshift.io/v1
grantMethod: auto
kind: OAuthClient
metadata:
...
accessTokenMaxAgeSeconds: 28800

You can configure OAuth tokens to have have a custom duration. By default, the tokens are valid for 24 hours (86400 seconds).

The maximum age can be either set in the OAuth server configuration or in any of the OAuth clients. The client settings override the OAuth server setting.

To set the OAuth server token max age, edit the OAuth server object: oc edit oauth cluster and set the .spec.tokenConfig.accessTokenMaxAgeSeconds parameter to the desired value:

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
...
spec:
   tokenConfig:
     accessTokenMaxAgeSeconds: 28800

You can configure OAuth tokens to expire after a set period of inactivity. By default, no token inactivity timeout is set.

The inactivity timeout can be either set in the OAuth server configuration or in any of the OAuth clients. The client settings override the OAuth server setting.

To edit the OAuth client inactivity timeout, edit the OAuth client object: oc edit oauthclient $clientname and set the top-level accessTokenInactivityTimeoutSeconds attribute.

apiVersion: oauth.openshift.io/v1
grantMethod: auto
kind: OAuthClient
metadata:
...
accessTokenInactivityTimeoutSeconds: 600 

You can configure OAuth tokens to have have a custom duration. By default, the tokens are valid for 24 hours (86400 seconds).

The maximum age can be either set in the OAuth server configuration or in any of the OAuth clients. The client settings override the OAuth server setting.

To set the OAuth client token max age, edit the OAuth client object: oc edit oauthclient $clientname and set the top-level accessTokenMaxAgeSeconds attribute.

apiVersion: oauth.openshift.io/v1
grantMethod: auto
kind: OAuthClient
metadata:
...
accessTokenMaxAgeSeconds: 28800

For users to interact with OpenShift Container Platform, they must first authenticate to the cluster. The authentication layer identifies the user associated with requests to the OpenShift Container Platform API. The authorization layer then uses information about the requesting user to determine if the request is allowed. Understanding authentication | Authentication | OpenShift Container Platform

The OpenShift Container Platform includes a built-in OAuth server for token-based authentication. Developers and administrators obtain OAuth access tokens to authenticate themselves to the API. It is recommended for an administrator to configure OAuth to specify an identity provider after the cluster is installed. User access to the cluster is managed through the identity provider. Understanding identity provider configuration | Authentication | OpenShift Container Platform

However, not all Identity Providers supported by OpenShift provide the same level of capabilities. As an example, the htpasswd Identity Provider only checks the username and password match and provides no means of 2FA, account lockout or notification mechanism. This rule therefore only allows a subset of identity providers.

For users to interact with OpenShift Container Platform, they must first authenticate to the cluster. The authentication layer identifies the user associated with requests to the OpenShift Container Platform API. The authorization layer then uses information about the requesting user to determine if the request is allowed. Understanding authentication | Authentication | OpenShift Container Platform

The OpenShift Container Platform includes a built-in OAuth server for token-based authentication. Developers and administrators obtain OAuth access tokens to authenticate themselves to the API. It is recommended for an administrator to configure OAuth to specify an identity provider after the cluster is installed. User access to the cluster is managed through the identity provider. Understanding identity provider configuration | Authentication | OpenShift Container Platform

If the identity provider is LDAP, setting the insecure flag to true would mean that passwords, such as the one used to authenticate the OAuth proxy to the LDAP server would be transmitted in the clear, potentially allowing an attacker to read the password if they captured the network traffic.