Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

Chapitre 10. En utilisant un compte de service en tant que client OAuth

10.1. Comptes de service en tant que clients OAuth
Copier lien

Il est possible d’utiliser un compte de service comme une forme restreinte de client OAuth. Les comptes de service ne peuvent demander qu’un sous-ensemble de portées qui permettent l’accès à certaines informations utilisateur de base et à la puissance basée sur les rôles à l’intérieur du propre espace de noms du compte de service:

  • l’utilisateur:info
  • accès utilisateur:check-access
  • le rôle:<any_role>:<service_account_namespace>
  • le rôle:<any_role>:<service_account_namespace>:!

Lors de l’utilisation d’un compte de service en tant que client OAuth:

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

  • client_secret peut être l’un des jetons API pour ce compte de service. À titre d’exemple: 

    $ oc sa get-token <service_account_name>
    Copy to Clipboard Toggle word wrap
  • Afin d’obtenir les défis WWW-Authenticate, définissez une annotation de serviceaccounts.openshift.io/oauth-want-want-challenges sur le compte de service à true.
  • redirect_uri doit correspondre à une annotation sur le compte de service.

Les clés d’annotation doivent avoir le préfixe serviceaccounts.openshift.io/oauth-redirecturi. ou serviceaccounts.openshift.io/oauth-redirectreference. 

serviceaccounts.openshift.io/oauth-redirecturi.<name>
Copy to Clipboard Toggle word wrap

Dans sa forme la plus simple, l’annotation peut être utilisée pour spécifier directement les URI de redirection valides. À titre d’exemple: 

"serviceaccounts.openshift.io/oauth-redirecturi.first":  "https://example.com"
"serviceaccounts.openshift.io/oauth-redirecturi.second": "https://other.com"
Copy to Clipboard Toggle word wrap

Les premier et deuxième postfixes de l’exemple ci-dessus sont utilisés pour séparer les deux URI de redirection valides.

Dans les configurations plus complexes, les URI de redirection statiques peuvent ne pas suffire. À titre d’exemple, vous voulez peut-être que toutes les Ingresses soient considérées comme valides. C’est là que la redirection dynamique des URIs via le préfixe serviceaccounts.openshift.io/oauth-redirectreference.

À titre d’exemple: 

"serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"
Copy to Clipboard Toggle word wrap

Étant donné que la valeur de cette annotation contient des données JSON sérialisées, il est plus facile de voir dans un format élargi: 

{
  "kind": "OAuthRedirectReference",
  "apiVersion": "v1",
  "reference": {
    "kind": "Route",
    "name": "jenkins"
  }
}
Copy to Clipboard Toggle word wrap

Désormais, vous pouvez voir qu’une OAuthRedirectReference nous permet de faire référence à l’itinéraire nommé jenkins. Ainsi, toutes les Ingresses pour cette route seront désormais considérées comme valides. La spécification complète d’une OAuthRedirectReference est: 

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

    "name": ...,
2 

    "group": ...
3 

  }
}
Copy to Clipboard Toggle word wrap
1
genre fait référence au type de l’objet référencé. Actuellement, seule la route est prise en charge.
2
le nom fait référence au nom de l’objet. L’objet doit être dans le même espace de noms que le compte de service.
3
le groupe fait référence au groupe de l’objet. Laissez ce vide, car le groupe pour un itinéraire est la chaîne vide.

Les deux préfixes d’annotation peuvent être combinés pour remplacer les données fournies par l’objet de référence. À titre d’exemple: 

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

Le premier postfix est utilisé pour lier les annotations ensemble. En supposant que la route des jenkins avait un Ingress de https://example.com, maintenant https://example.com/custompath est considéré comme valide, mais https://example.com ne l’est pas. Le format pour fournir partiellement des données de substitution est le suivant:

Expand
Le typeSyntaxe

Le plan d’action

"HTTPS://"

Le nom d’hôte

"//site.com"

Le port

"//:8000"

Le chemin

« exemple »

Note

La spécification d’un nom d’hôte remplace les données du nom d’hôte de l’objet référencé, ce qui n’est pas susceptible d’être un comportement souhaité.

Chaque combinaison de la syntaxe ci-dessus peut être combinée en utilisant le format suivant:

&lt;Scheme:&gt;//&lt;nom d’hôte&gt;&lt;:port&gt;/&lt;path&gt;

Le même objet peut être référencé plus d’une fois pour plus de flexibilité: 

"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\"}}"
Copy to Clipboard Toggle word wrap

En supposant que l’itinéraire nommé jenkins dispose d’un Ingress de https://example.com, alors https://example.com:8000 et ▲ sont considérés comme valides.

Les annotations statiques et dynamiques peuvent être utilisées en même temps pour atteindre le comportement souhaité: 

"serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"
"serviceaccounts.openshift.io/oauth-redirecturi.second": "https://other.com"
Copy to Clipboard Toggle word wrap
Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat