Using a service account as an OAuth client

    • user:check-access

    • role:<any_role>:<service_account_namespace>

    • role:<any_role>:<service_account_namespace>:!

    When using a service account as an OAuth client:

    • client_id is system:serviceaccount:<service_account_namespace>:<service_account_name>.

    • client_secret can be any of the API tokens for that service account. For example:

    • To get WWW-Authenticate challenges, set an serviceaccounts.openshift.io/oauth-want-challenges annotation on the service account to true.

    • redirect_uri must match an annotation on the service account.

    Annotation keys must have the prefix serviceaccounts.openshift.io/oauth-redirecturi. or serviceaccounts.openshift.io/oauth-redirectreference. such as:

    1. serviceaccounts.openshift.io/oauth-redirecturi.<name>
    1. "serviceaccounts.openshift.io/oauth-redirecturi.first":  "https://example.com"

    The first and second postfixes in the above example are used to separate the two valid redirect URIs.

    In more complex configurations, static redirect URIs may not be enough. For example, perhaps you want all Ingresses for a route to be considered valid. This is where dynamic redirect URIs via the serviceaccounts.openshift.io/oauth-redirectreference. prefix come into play.

    For example:

    Since the value for this annotation contains serialized JSON data, it is easier to see in an expanded format:

    3.   "kind": "OAuthRedirectReference",
    4.   "apiVersion": "v1",
    5.   "reference": {
    6.     "kind": "Route",
    7.     "name": "jenkins"
    8.   }
    9. }

    Now you can see that an OAuthRedirectReference allows us to reference the route named jenkins. Thus, all Ingresses for that route will now be considered valid. The full specification for an OAuthRedirectReference is:

    2. {
    3.   "kind": "OAuthRedirectReference",
    4.   "reference": {
    5.     "kind": ..., (1)
    6.     "name": ..., (2)
    7.     "group": ... (3)
    8.   }

    Both annotation prefixes can be combined to override the data provided by the reference object. For example:

    The first postfix is used to tie the annotations together. Assuming that the jenkins route had an Ingress of https://example.com, now https://example.com/custompath is considered valid, but https://example.com is not. The format for partially supplying override data is as follows:

    Any combination of the above syntax can be combined using the following format:

    <scheme:>//<hostname><:port>/<path>

    The same object can be referenced more than once for more flexibility:

    1. "serviceaccounts.openshift.io/oauth-redirecturi.first":  "custompath"
    2. "serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"
    3. "serviceaccounts.openshift.io/oauth-redirecturi.second":  "//:8000"
    4. "serviceaccounts.openshift.io/oauth-redirectreference.second": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"

    Assuming that the route named jenkins has an Ingress of https://example.com, then both https://example.com:8000 and https://example.com/custompath are considered valid.

    Static and dynamic annotations can be used at the same time to achieve the desired behavior:

    1. "serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"