From a3f977aaec05b09b5fe20c749703c7ece1e8546c Mon Sep 17 00:00:00 2001 From: Cheikhrouhou ines Date: Thu, 12 Sep 2019 21:58:31 +0200 Subject: [PATCH 1/3] translate service account fr --- .../configure-service-account.md | 288 ++++++++++++++++++ .../pods/pod-projected-svc-token.yaml | 20 ++ 2 files changed, 308 insertions(+) create mode 100644 content/fr/docs/tasks/configure-pod-container/configure-service-account.md create mode 100644 content/fr/examples/pods/pod-projected-svc-token.yaml diff --git a/content/fr/docs/tasks/configure-pod-container/configure-service-account.md b/content/fr/docs/tasks/configure-pod-container/configure-service-account.md new file mode 100644 index 0000000000..c90a7de585 --- /dev/null +++ b/content/fr/docs/tasks/configure-pod-container/configure-service-account.md @@ -0,0 +1,288 @@ +--- +title: Configurer les comptes de service pour les pods +content_template: templates/task +weight: 90 +--- + +{{% capture overview %}} +Un compte de service fournit une identité pour les processus qui s'exécutent dans un Pod. + +*Ceci est une introduction aux comptes de service pour les utilisateurs. Voir aussi +[Guide de l'administrateur du cluster des comptes de service](/docs/reference/access-authn-authz/service-accounts-admin/).* + +{{< note >}} +Ce document décrit le comportement des comptes de service dans un cluster mis en place conformément aux recommandations du projet Kubernetes. L'administrateur de votre cluster a peut-être personnalisé le comportement dans votre cluster, dans ce cas cette documentation pourrait être non applicable. +{{< /note >}} + +Lorsque vous (un humain) accédez au cluster (par exemple, en utilisant `kubectl`), vous êtes +authentifié par l'apiserver en tant que compte d'utilisateur particulier (actuellement, il s'agit +généralement de l'utilisateur `admin`, à moins que votre administrateur de cluster n'ait personnalisé votre cluster).Les processus dans les conteneurs dans les pods peuvent également contacter l'apiserver. Dans ce cas, ils sont authentifiés en tant que compte de service particulier (par exemple, `default`). + +{{% /capture %}} + + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{% /capture %}} + +{{% capture steps %}} + +## Utiliser le compte de service par défaut pour accéder au API server. + +Si vous obtenez le raw json ou yaml pour un pod que vous avez créé (par exemple, `kubectl get pods/ -o yaml`), vous pouvez voir que le champ `spec.serviceAccountName` a été [automatiquement assigné](/docs/user-guide/working-with-resources/#resources-are-automatically-modified). + +Vous pouvez accéder à l'API depuis l'intérieur d'un pod en utilisant les identifiants de compte de service montés automatiquement, comme décrit dans [Accès au cluster](/docs/user-guide/accessing-the-cluster/#accessing-the-api-from-a-pod). +Les permissions API du compte de service dépendent du [plugin d'autorisation et de la politique](/docs/reference/access-authn-authz/authorization/#authorization-modules) en usage. + +Dans la version 1.6+, vous pouvez choisir de ne pas utiliser le montage automatique des identifiants API pour un compte de service en définissant `automountServiceAccountToken : false` sur le compte de service : + +```yaml +apiVersion: v1 +kind: ServiceAccount +metadata: + name: build-robot +automountServiceAccountToken: false +... +``` + +Dans la version 1.6+, vous pouvez également choisir de ne pas monter automatiquement les identifiants API pour un pod particulier : + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: my-pod +spec: + serviceAccountName: build-robot + automountServiceAccountToken: false + ... +``` + +La spéc de pod a prépondérance par rapport au compte de service si les deux spécifient la valeur `automountServiceAccountToken`. + +## Utiliser plusieurs comptes de services. + +Chaque namespace possède une ressource de compte de service par défaut appelée `default`. +Vous pouvez lister cette ressource et toutes les autres ressources de serviceAccount dans le namespace avec cette commande : + +```shell +kubectl get serviceAccounts +``` +La sortie est comme la suivante : + +``` +NAME SECRETS AGE +default 1 1d +``` + +Vous pouvez créer des objets ServiceAccount supplémentaires comme ceci : + +```shell +kubectl apply -f - < +Annotations: kubernetes.io/service-account.name=build-robot + kubernetes.io/service-account.uid=da68f9c6-9d26-11e7-b84e-002dc52800da + +Type: kubernetes.io/service-account-token + +Data +==== +ca.crt: 1338 bytes +namespace: 7 bytes +token: ... +``` + +{{< note >}} +Le contenu de `token` est éludé ici. +{{< /note >}} + +## Ajouter ImagePullSecrets à un compte de service + +Tout d'abord, créez un imagePullSecret, comme décrit [ici](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod). +Puis, vérifiez qu'il a été créé. Par exemple : + +```shell +kubectl get secrets myregistrykey +``` + +La sortie est comme la suivante : + +``` +NAME TYPE DATA AGE +myregistrykey   kubernetes.io/.dockerconfigjson   1       1d +``` + +Ensuite, modifiez le compte de service par défaut du namespace pour utiliser ce secret comme un imagePullSecret. + +```shell +kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}' +``` + +La version interactive nécessite un traitement manuel : + +```shell +kubectl get serviceaccounts default -o yaml > ./sa.yaml +``` + +La sortie du fichier `sa.yaml` est similaire à celle-ci : + +```shell +apiVersion: v1 +kind: ServiceAccount +metadata: + creationTimestamp: 2015-08-07T22:02:39Z + name: default + namespace: default + resourceVersion: "243024" + selfLink: /api/v1/namespaces/default/serviceaccounts/default + uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6 +secrets: +- name: default-token-uudge +``` + +En utilisant l'éditeur de votre choix (par exemple `vi`), ouvrez le fichier `sa.yaml`, supprimez la ligne avec la clé `resourceVersion`, ajouter les lignes avec `imagePullSecrets:` et sauvegarder. + +La sortie du fichier `sa.yaml` est similaire à celle-ci : + +```shell +apiVersion: v1 +kind: ServiceAccount +metadata: + creationTimestamp: 2015-08-07T22:02:39Z + name: default + namespace: default + selfLink: /api/v1/namespaces/default/serviceaccounts/default + uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6 +secrets: +- name: default-token-uudge +imagePullSecrets: +- name: myregistrykey +``` + +Enfin, remplacez le compte de service par le nouveau fichier `sa.yaml` mis à jour. + +```shell +kubectl replace serviceaccount default -f ./sa.yaml +``` + +Maintenant, tous les nouveaux pods créés dans le namespace courant auront ceci ajouté à leurs spécifications : + +```yaml +spec: + imagePullSecrets: + - name: myregistrykey +``` + + + +## Projection du volume des tokens de compte de service + +{{< feature-state for_k8s_version="v1.12" state="beta" >}} + +{{< note >}} +Ce ServiceAccountTokenVolumeProjection est __beta__ en 1.12 et +activé en passant tous les paramètres suivants au serveur API : + +* `--service-account-issuer` +* `--service-account-signing-key-file` +* `--service-account-api-audiences` + +{{< /note >}} + +Le kubelet peut également projeter un token de compte de service dans un Pod. Vous pouvez spécifier les propriétés souhaitées du token, telles que l'audience et la durée de validité. +Ces propriétés ne sont pas configurables sur le compte de service par défaut. Le token de compte de service devient également invalide par l'API lorsque le Pod ou le ServiceAccount est supprimé + +Ce comportement est configuré sur un PodSpec utilisant un type de ProjectedVolume appelé +[ServiceAccountToken](/docs/concepts/storage/volumes/#projected). Pour fournir un +pod avec un token avec une audience de "vault" et une durée de validité de deux heures, vous devriez configurer ce qui suit dans votre PodSpec : + +{{< codenew file="pods/pod-projected-svc-token.yaml" >}} + +Créez le pod + +```shell +kubectl create -f https://k8s.io/examples/pods/pod-projected-svc-token.yaml +``` + +Le kubelet demandera et stockera le token a la place du pod, rendra le token disponible pour le pod à un chemin d'accès configurable, et rafraîchissez le token à l'approche de son expiration. Kubelet fait tourner le token de manière proactive s'il est plus vieux que 80% de son TTL total, ou si le token est plus vieux que 24 heures. + +L'application est responsable du rechargement du token lorsqu'il tourne. Un rechargement périodique (par ex. toutes les 5 minutes) est suffisant pour la plupart des cas d'utilisation. + +{{% /capture %}} diff --git a/content/fr/examples/pods/pod-projected-svc-token.yaml b/content/fr/examples/pods/pod-projected-svc-token.yaml new file mode 100644 index 0000000000..985073c8d3 --- /dev/null +++ b/content/fr/examples/pods/pod-projected-svc-token.yaml @@ -0,0 +1,20 @@ +apiVersion: v1 +kind: Pod +metadata: + name: nginx +spec: + containers: + - image: nginx + name: nginx + volumeMounts: + - mountPath: /var/run/secrets/tokens + name: vault-token + serviceAccountName: build-robot + volumes: + - name: vault-token + projected: + sources: + - serviceAccountToken: + path: vault-token + expirationSeconds: 7200 + audience: vault From 496fad77bbf9a1362c332fdfca26f7c876532c02 Mon Sep 17 00:00:00 2001 From: Cheikhrouhou ines Date: Fri, 20 Dec 2019 16:52:34 +0100 Subject: [PATCH 2/3] renaming and fix for service account fr --- .../configure-service-account.md | 44 +++++++++---------- 1 file changed, 22 insertions(+), 22 deletions(-) diff --git a/content/fr/docs/tasks/configure-pod-container/configure-service-account.md b/content/fr/docs/tasks/configure-pod-container/configure-service-account.md index c90a7de585..872256503b 100644 --- a/content/fr/docs/tasks/configure-pod-container/configure-service-account.md +++ b/content/fr/docs/tasks/configure-pod-container/configure-service-account.md @@ -5,7 +5,7 @@ weight: 90 --- {{% capture overview %}} -Un compte de service fournit une identité pour les processus qui s'exécutent dans un Pod. +Un ServiceAccount (compte de service) fournit une identité pour les processus qui s'exécutent dans un Pod. *Ceci est une introduction aux comptes de service pour les utilisateurs. Voir aussi [Guide de l'administrateur du cluster des comptes de service](/docs/reference/access-authn-authz/service-accounts-admin/).* @@ -16,7 +16,7 @@ Ce document décrit le comportement des comptes de service dans un cluster mis e Lorsque vous (un humain) accédez au cluster (par exemple, en utilisant `kubectl`), vous êtes authentifié par l'apiserver en tant que compte d'utilisateur particulier (actuellement, il s'agit -généralement de l'utilisateur `admin`, à moins que votre administrateur de cluster n'ait personnalisé votre cluster).Les processus dans les conteneurs dans les pods peuvent également contacter l'apiserver. Dans ce cas, ils sont authentifiés en tant que compte de service particulier (par exemple, `default`). +généralement de l'utilisateur `admin`, à moins que votre administrateur de cluster n'ait personnalisé votre cluster). Les processus dans les conteneurs dans les Pods peuvent également contacter l'apiserver. Dans ce cas, ils sont authentifiés en tant que compte de service particulier (par exemple, `default`). {{% /capture %}} @@ -31,12 +31,12 @@ généralement de l'utilisateur `admin`, à moins que votre administrateur de cl ## Utiliser le compte de service par défaut pour accéder au API server. -Si vous obtenez le raw json ou yaml pour un pod que vous avez créé (par exemple, `kubectl get pods/ -o yaml`), vous pouvez voir que le champ `spec.serviceAccountName` a été [automatiquement assigné](/docs/user-guide/working-with-resources/#resources-are-automatically-modified). +Si vous obtenez le raw json ou yaml pour un Pod que vous avez créé (par exemple, `kubectl get pods/ -o yaml`), vous pouvez voir que le champ `spec.serviceAccountName` a été [automatiquement assigné](/docs/user-guide/working-with-resources/#resources-are-automatically-modified). -Vous pouvez accéder à l'API depuis l'intérieur d'un pod en utilisant les identifiants de compte de service montés automatiquement, comme décrit dans [Accès au cluster](/docs/user-guide/accessing-the-cluster/#accessing-the-api-from-a-pod). +Vous pouvez accéder à l'API depuis l'intérieur d'un Pod en utilisant les identifiants de compte de service montés automatiquement, comme décrit dans [Accès au cluster](/docs/user-guide/accessing-the-cluster/#accessing-the-api-from-a-pod). Les permissions API du compte de service dépendent du [plugin d'autorisation et de la politique](/docs/reference/access-authn-authz/authorization/#authorization-modules) en usage. -Dans la version 1.6+, vous pouvez choisir de ne pas utiliser le montage automatique des identifiants API pour un compte de service en définissant `automountServiceAccountToken : false` sur le compte de service : +Dans la version 1.6+, vous pouvez choisir de ne pas utiliser le montage automatique des identifiants API pour un compte de service en définissant `automountServiceAccountToken: false` sur le compte de service : ```yaml apiVersion: v1 @@ -47,7 +47,7 @@ automountServiceAccountToken: false ... ``` -Dans la version 1.6+, vous pouvez également choisir de ne pas monter automatiquement les identifiants API pour un pod particulier : +Dans la version 1.6+, vous pouvez également choisir de ne pas monter automatiquement les identifiants API pour un Pod particulier : ```yaml apiVersion: v1 @@ -60,12 +60,12 @@ spec: ... ``` -La spéc de pod a prépondérance par rapport au compte de service si les deux spécifient la valeur `automountServiceAccountToken`. +La spéc de Pod a prépondérance par rapport au compte de service si les deux spécifient la valeur `automountServiceAccountToken`. ## Utiliser plusieurs comptes de services. -Chaque namespace possède une ressource de compte de service par défaut appelée `default`. -Vous pouvez lister cette ressource et toutes les autres ressources de serviceAccount dans le namespace avec cette commande : +Chaque Namespace possède une ressource ServiceAccount par défaut appelée `default`. +Vous pouvez lister cette ressource et toutes les autres ressources de ServiceAccount dans le Namespace avec cette commande : ```shell kubectl get serviceAccounts @@ -111,13 +111,13 @@ secrets: vous verrez alors qu'un token a été automatiquement créé et est référencé par le compte de service. -Vous pouvez utiliser des plugins d'autorisation pour[définir les permissions sur les comptes de service](/docs/reference/access-authn-authz/rbac/#service-account-permissions). +Vous pouvez utiliser des plugins d'autorisation pour [définir les permissions sur les comptes de service](/docs/reference/access-authn-authz/rbac/#service-account-permissions). -Pour utiliser un compte de service autre que par défaut, il suffit de spécifier le `spec.serviceAccountName` d'un pod au nom du compte de service que vous souhaitez utiliser. +Pour utiliser un compte de service autre que par défaut, il suffit de spécifier le `spec.serviceAccountName` d'un Pod au nom du compte de service que vous souhaitez utiliser. -Le compte de service doit exister au moment de la création du pod, sinon il sera rejeté. +Le compte de service doit exister au moment de la création du Pod, sinon il sera rejeté. -Vous ne pouvez pas mettre à jour le compte de service d'un pod déjà créé. +Vous ne pouvez pas mettre à jour le compte de service d'un Pod déjà créé. Vous pouvez supprimer le compte de service de cet exemple comme ceci : @@ -127,7 +127,7 @@ kubectl delete serviceaccount/build-robot ## Créez manuellement un API token de compte de service. -Supposons que nous ayons un compte de service existant nommé "build-robot" comme mentionné ci-dessus,et que nous allons créer un nouveau secret manuellement. +Supposons que nous ayons un compte de service existant nommé "build-robot" comme mentionné ci-dessus,et que nous allons créer un nouveau Secret manuellement. ```shell kubectl apply -f - <}} -Le kubelet peut également projeter un token de compte de service dans un Pod. Vous pouvez spécifier les propriétés souhaitées du token, telles que l'audience et la durée de validité. +Kubelet peut également projeter un token de compte de service dans un Pod. Vous pouvez spécifier les propriétés souhaitées du token, telles que l'audience et la durée de validité. Ces propriétés ne sont pas configurables sur le compte de service par défaut. Le token de compte de service devient également invalide par l'API lorsque le Pod ou le ServiceAccount est supprimé Ce comportement est configuré sur un PodSpec utilisant un type de ProjectedVolume appelé [ServiceAccountToken](/docs/concepts/storage/volumes/#projected). Pour fournir un -pod avec un token avec une audience de "vault" et une durée de validité de deux heures, vous devriez configurer ce qui suit dans votre PodSpec : +Pod avec un token avec une audience de "vault" et une durée de validité de deux heures, vous devriez configurer ce qui suit dans votre PodSpec : {{< codenew file="pods/pod-projected-svc-token.yaml" >}} -Créez le pod +Créez le Pod ```shell kubectl create -f https://k8s.io/examples/pods/pod-projected-svc-token.yaml ``` -Le kubelet demandera et stockera le token a la place du pod, rendra le token disponible pour le pod à un chemin d'accès configurable, et rafraîchissez le token à l'approche de son expiration. Kubelet fait tourner le token de manière proactive s'il est plus vieux que 80% de son TTL total, ou si le token est plus vieux que 24 heures. +Kubelet demandera et stockera le token a la place du Pod, rendra le token disponible pour le Pod à un chemin d'accès configurable, et rafraîchissez le token à l'approche de son expiration. Kubelet fait tourner le token de manière proactive s'il est plus vieux que 80% de son TTL total, ou si le token est plus vieux que 24 heures. -L'application est responsable du rechargement du token lorsqu'il tourne. Un rechargement périodique (par ex. toutes les 5 minutes) est suffisant pour la plupart des cas d'utilisation. +L'application est responsable du rechargement du token lorsque celui ci est renouvelé. Un rechargement périodique (par ex. toutes les 5 minutes) est suffisant pour la plupart des cas d'utilisation. {{% /capture %}} From 40496c2b7d8e2dc9f47f2da21c1ede2db6b93420 Mon Sep 17 00:00:00 2001 From: icheikhrouhou Date: Mon, 13 Apr 2020 10:18:36 +0200 Subject: [PATCH 3/3] fix translate configure service account --- .../configure-pod-container/configure-service-account.md | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/content/fr/docs/tasks/configure-pod-container/configure-service-account.md b/content/fr/docs/tasks/configure-pod-container/configure-service-account.md index 872256503b..5d8df1af62 100644 --- a/content/fr/docs/tasks/configure-pod-container/configure-service-account.md +++ b/content/fr/docs/tasks/configure-pod-container/configure-service-account.md @@ -214,7 +214,7 @@ secrets: - name: default-token-uudge ``` -En utilisant l'éditeur de votre choix (par exemple `vi`), ouvrez le fichier `sa.yaml`, supprimez la ligne avec la clé `resourceVersion`, ajouter les lignes avec `imagePullSecrets:` et sauvegarder. +En utilisant l'éditeur de votre choix (par exemple `vi`), ouvrez le fichier `sa.yaml`, supprimez la ligne avec la clé `resourceVersion`, ajoutez les lignes avec `imagePullSecrets:` et sauvegardez. La sortie du fichier `sa.yaml` est similaire à celle-ci : @@ -247,11 +247,6 @@ spec: - name: myregistrykey ``` - - ## Projection du volume des tokens de compte de service {{< feature-state for_k8s_version="v1.12" state="beta" >}}