Red Hat Summit Red Hat SummitSupportKonsoleEntwicklerDemo startenKontakt

Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.

Chapter 12. Using a service account as an OAuth client

12.1. Service accounts as OAuth clients
Link kopieren

You can use a service account as a constrained form of OAuth client. Service accounts can request only a subset of scopes that allow access to some basic user information and role-based power inside of the service account’s own namespace: 

  • user:info
     
  • 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: 

    $ oc sa get-token <service_account_name>
  • 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.

12.1.1. Redirect URIs for service accounts as OAuth clients
Link kopieren

Annotation keys must have the prefix 

serviceaccounts.openshift.io/oauth-redirecturi.
or 
serviceaccounts.openshift.io/oauth-redirectreference.
such as: 

serviceaccounts.openshift.io/oauth-redirecturi.<name>

In its simplest form, the annotation can be used to directly specify valid redirect URIs. For example: 

"serviceaccounts.openshift.io/oauth-redirecturi.first":  "https://example.com"
"serviceaccounts.openshift.io/oauth-redirecturi.second": "https://other.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: 

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

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

{
  "kind": "OAuthRedirectReference",
  "apiVersion": "v1",
  "reference": {
    "kind": "Route",
    "name": "jenkins"
  }
}

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: 

{
  "kind": "OAuthRedirectReference",
  "apiVersion": "v1",
  "reference": {
    "kind": ...,
1 

    "name": ...,
2 

    "group": ...
3 

  }
}
1
kind refers to the type of the object being referenced. Currently, only route is supported.
2
name refers to the name of the object. The object must be in the same namespace as the service account.
3
group refers to the group of the object. Leave this blank, as the group for a route is the empty string.

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

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

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:

Expand
TypeSyntax

Scheme

"https://"

Hostname

"//website.com"

Port

"//:8000"

Path

"examplepath"

Note

Specifying a hostname override will replace the hostname data from the referenced object, which is not likely to be desired behavior.

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: 

"serviceaccounts.openshift.io/oauth-redirecturi.first":  "custompath"
"serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"
"serviceaccounts.openshift.io/oauth-redirecturi.second":  "//:8000"
"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: 

"serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"
"serviceaccounts.openshift.io/oauth-redirecturi.second": "https://other.com"
Red Hat logoGithubredditYoutubeTwitter

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat Dokumentation

Wir helfen Red Hat Benutzern, mit unseren Produkten und Diensten innovativ zu sein und ihre Ziele zu erreichen – mit Inhalten, denen sie vertrauen können. Entdecken Sie unsere neuesten Updates.

Mehr Inklusion in Open Source

Red Hat hat sich verpflichtet, problematische Sprache in unserem Code, unserer Dokumentation und unseren Web-Eigenschaften zu ersetzen. Weitere Einzelheiten finden Sie in Red Hat Blog.

Über Red Hat

Wir liefern gehärtete Lösungen, die es Unternehmen leichter machen, plattform- und umgebungsübergreifend zu arbeiten, vom zentralen Rechenzentrum bis zum Netzwerkrand.

Theme

© 2026 Red HatNach oben