Configuring the internal OAuth server

• OKD OAuth server
• OAuth token request flows and responses
• Options for the internal OAuth server
  • OAuth token duration options
  • OAuth grant options
• Configuring the internal OAuth server’s token duration
• Configuring token inactivity timeout for the internal OAuth server
• Customizing the internal OAuth server URL
• OAuth server metadata
• Troubleshooting OAuth API events

OKD OAuth server

The OKD master includes a built-in OAuth server. Users obtain OAuth access tokens to authenticate themselves to the API.

When a person requests a new OAuth token, the OAuth server uses the configured identity provider to determine the identity of the person making the request.

It then determines what user that identity maps to, creates an access token for that user, and returns the token for use.

OAuth token request flows and responses

The OAuth server supports standard authorization code grant and the implicit grant OAuth authorization flows.

When requesting an OAuth token using the implicit grant flow (response_type=token) with a client_id configured to request WWW-Authenticate challenges (like openshift-challenging-client), these are the possible server responses from /oauth/authorize, and how they should be handled:

Options for the internal OAuth server

Several configuration options are available for the internal OAuth server.

OAuth token duration options

The internal OAuth server generates two kinds of tokens:

You can configure the default duration for both types of token. If necessary, you can override the duration of the access token by using an OAuthClient object definition.

OAuth grant options

When the OAuth server receives token requests for a client to which the user has not previously granted permission, the action that the OAuth server takes is dependent on the OAuth client’s grant strategy.

The OAuth client requesting token must provide its own grant strategy.

You can apply the following default methods:

Configuring the internal OAuth server’s token duration

You can configure default options for the internal OAuth server’s token duration.

If the default time is insufficient, then this can be modified using the following procedure.

Procedure

1. Create a configuration file that contains the token duration options. The following file sets this to 48 hours, twice the default.

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

   1	Set accessTokenMaxAgeSeconds to control the lifetime of access tokens. The default lifetime is 24 hours, or 86400 seconds. This attribute cannot be negative. If set to zero, the default lifetime is used.

2. Apply the new configuration file:

   Because you update the existing OAuth server, you must use the oc apply command to apply the change.

   $ oc apply -f </path/to/file.yaml>

3. Confirm that the changes are in effect:

   $ oc describe oauth.config.openshift.io/cluster

   Example output

   ...
   Spec:
     Token Config:
       Access Token Max Age Seconds:  172800
   ...

Configuring token inactivity timeout for the internal OAuth server

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

Prerequisites

• You have access to the cluster as a user with the cluster-admin role.

• You have configured an identity provider (IDP).

Procedure

1. Update the OAuth configuration to set a token inactivity timeout.

   1. Edit the OAuth object:

      $ oc edit oauth cluster

      Add the spec.tokenConfig.accessTokenInactivityTimeout field and set your timeout value:

      apiVersion: config.openshift.io/v1
      kind: OAuth
      metadata:
      ...
      spec:
        tokenConfig:
          accessTokenInactivityTimeout: 400s (1)

      1	Set a value with the appropriate units, for example 400s for 400 seconds, or 30m for 30 minutes. The minimum allowed timeout value is 300s.

   2. Save the file to apply the changes.

2. Check that the OAuth server pods have restarted:

   $ oc get clusteroperators authentication

   Do not continue to the next step until PROGRESSING is listed as False, as shown in the following output:

   Example output

   NAME             VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
   authentication   4.9.0     True        False         False      145m

3. Check that a new revision of the Kubernetes API server pods has rolled out. This will take several minutes.

   $ oc get clusteroperators kube-apiserver

   Do not continue to the next step until PROGRESSING is listed as False, as shown in the following output:

   Example output

   NAME             VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
   kube-apiserver   4.9.0     True        False         False      145m

   If PROGRESSING is showing True, wait a few minutes and try again.

Verification

1. Log in to the cluster with an identity from your IDP.

2. Execute a command and verify that it was successful.

3. Wait longer than the configured timeout without using the identity. In this procedure’s example, wait longer than 400 seconds.

4. Try to execute a command from the same identity’s session.

   This command should fail because the token should have expired due to inactivity longer than the configured timeout.

   Example output

   error: You must be logged in to the server (Unauthorized)

Customizing the internal OAuth server URL

You can customize the internal OAuth server URL by setting the custom hostname and TLS certificate in the spec.componentRoutes field of the cluster Ingress configuration.

$ oc login -u <username> -p <password> —certificate-authority=<path_to_ca.crt> (1)

Prerequisites

• You have logged in to the cluster as a user with administrative privileges.

• You have created a secret in the openshift-config namespace containing the TLS certificate and key. This is required if the domain for the custom hostname suffix does not match the cluster domain suffix. The secret is optional if the suffix matches.

  You can create a TLS secret by using the oc create secret tls command.

Procedure

1. Edit the cluster Ingress configuration:

   $ oc edit ingress.config.openshift.io cluster

2. Set the custom hostname and optionally the serving certificate and key:

   apiVersion: config.openshift.io/v1
   kind: Ingress
   metadata:
     name: cluster
   spec:
     componentRoutes:
       - name: oauth-openshift
         namespace: openshift-authentication
         hostname: <custom_hostname> (1)
         servingCertKeyPairSecret:
           name: <secret_name> (2)

   1	The custom hostname.
   2	Reference to a secret in the openshift-config namespace that contains a TLS certificate (tls.crt) and key (tls.key). This is required if the domain for the custom hostname suffix does not match the cluster domain suffix. The secret is optional if the suffix matches.

3. Save the file to apply the changes.

OAuth server metadata

Applications running in OKD might have to discover information about the built-in OAuth server. For example, they might have to discover what the address of the <namespace_route> is without manual configuration. To aid in this, OKD implements the IETF OAuth 2.0 Authorization Server Metadata draft specification.

Thus, any application running inside the cluster can issue a GET request to https://openshift.default.svc/.well-known/oauth-authorization-server to fetch the following information:

{
  "issuer": "https://<namespace_route>", (1)
  "authorization_endpoint": "https://<namespace_route>/oauth/authorize", (2)
  "token_endpoint": "https://<namespace_route>/oauth/token", (3)
  "scopes_supported": [ (4)
    "user:full",
    "user:info",
    "user:check-access",
    "user:list-scoped-projects",
    "user:list-projects"
  ],
  "response_types_supported": [ (5)
    "code",
    "token"
  ],
  "grant_types_supported": [ (6)
    "authorization_code",
    "implicit"
  ],
  "code_challenge_methods_supported": [ (7)
    "plain",
    "S256"
  ]
}

Troubleshooting OAuth API events

In some cases the API server returns an unexpected condition error message that is difficult to debug without direct access to the API master log. The underlying reason for the error is purposely obscured in order to avoid providing an unauthenticated user with information about the server’s state.

A subset of these errors is related to service account OAuth configuration issues. These issues are captured in events that can be viewed by non-administrator users. When encountering an unexpected condition server error during OAuth, run oc get events to view these events under ServiceAccount.

The following example warns of a service account that is missing a proper OAuth redirect URI:

$ oc get events | grep ServiceAccount

Example output

1m         1m          1         proxy                    ServiceAccount                                  Warning   NoSAOAuthRedirectURIs   service-account-oauth-client-getter   system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>

Running oc describe sa/<service_account_name> reports any OAuth events associated with the given service account name.

$ oc describe sa/proxy | grep -A5 Events

Example output

Events:
  FirstSeen     LastSeen        Count   From                                    SubObjectPath   Type            Reason                  Message
  ---------     --------        -----   ----                                    -------------   --------        ------                  -------
  3m            3m              1       service-account-oauth-client-getter                     Warning         NoSAOAuthRedirectURIs   system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>

The following is a list of the possible event errors:

No redirect URI annotations or an invalid URI is specified

Reason                  Message
NoSAOAuthRedirectURIs   system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>

Invalid route specified

Reason                  Message
NoSAOAuthRedirectURIs   [routes.route.openshift.io "<name>" not found, system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>]

Invalid reference type specified

Reason                  Message
NoSAOAuthRedirectURIs   [no kind "<name>" is registered for version "v1", system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>]

Missing SA tokens

Reason                  Message
NoSAOAuthTokens         system:serviceaccount:myproject:proxy has no tokens