From cf7fc142aab9e339c8f8869ebc49f32c16a42ca7 Mon Sep 17 00:00:00 2001 From: vincent Date: Tue, 17 Jan 2023 03:16:17 +0000 Subject: [PATCH 01/14] start translate rbac in french --- .../docs/reference/access-authn-authz/rbac.md | 1293 +++++++++++++++++ 1 file changed, 1293 insertions(+) create mode 100644 content/fr/docs/reference/access-authn-authz/rbac.md diff --git a/content/fr/docs/reference/access-authn-authz/rbac.md b/content/fr/docs/reference/access-authn-authz/rbac.md new file mode 100644 index 00000000000..cbffa267bcf --- /dev/null +++ b/content/fr/docs/reference/access-authn-authz/rbac.md @@ -0,0 +1,1293 @@ +--- +title: Utilisation de l'autorisation RBAC +content_type: concept +aliases: [/fr/rbac/] +weight: 70 +--- + + + + +Le contrôle d'accès basé sur les rôles (RBAC) est une méthode permettant de +réguler l'accès aux ressources informatiques ou réseau en fonction des rôles des +utilisateurs individuels au sein de votre organisation. + + + +L'autorisation RBAC utilise le `rbac.authorization.k8s.io` +{{< glossary_tooltip text="API group" term_id="api-group" >}} pour prendre les +décisions d'autorisation, ce qui vous permet de configurer +dynamiquement les politiques via l'API Kubernetes. + +Pour activer RBAC, démarrez le {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} +avec l'indicateur `--authorization-mode` défini sur une liste séparée par des virgules qui inclut `RBAC` ; +par exemple : +```shell +kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options +``` + +## Objets de l'API {#api-overview} + +L'API RBAC déclare quatre types d'objets Kubernetes : _Role_, _ClusterRole_, +_RoleBinding_ et _ClusterRoleBinding_. Vous pouvez +[décrire les objets](/docs/concepts/overview/working-with-objects/kubernetes-objects/#understanding-kubernetes-objects), +ou les modifier, en utilisant des outils tels que `kubectl`, comme tout autre objet Kubernetes. + +{{< caution >}} +Ces objets, de par leur conception, imposent des restrictions d'accès. Si vous apportez des modifications +à un cluster au fur et à mesure de votre apprentissage, consultez +[prévention de l'escalade des privilèges et amorçage](#privilege-escalation-prevention-and-bootstrapping) +pour comprendre comment ces restrictions peuvent vous empêcher d'effectuer certaines modifications. +{{< /caution >}} + +### Role and ClusterRole + +Un _Role_ ou _ClusterRole_ RBAC contient des règles qui représentent un ensemble de permissions. +Les permissions sont purement additives (il n'y a pas de "deny" règles). + +A Role always sets permissions within a particular {{< glossary_tooltip text="namespace" term_id="namespace" >}}; +when you create a Role, you have to specify the namespace it belongs in. +Un rôle définit toujours les autorisations dans un {{< glossary_tooltip text="namespace" term_id="namespace" >}} particulier; +lorsque vous créez un Role, vous devez spécifier le namespace auquel il appartient. + +ClusterRole, by contrast, is a non-namespaced resource. The resources have different names (Role +and ClusterRole) because a Kubernetes object always has to be either namespaced or not namespaced; +it can't be both. +ClusterRole, en revanche, est une ressource sans namespace. Les ressources portent des noms différents (Role +et ClusterRole) parce qu'un objet Kubernetes doit toujours être soit avec un namespace ou soit sans namespace; +Il ne peut pas être les deux. + +Les ClusterRoles ont plusieurs usages. Vous pouvez utiliser une ClusterRole pour : + +1. définir les autorisations sur les ressources avec un namespace et obtenir l'accès à l'intérieur d'un ou plusieurs namespaces +1. définir les permissions sur les ressources avec un namespace et obtenir l'accès à travers tous les namespaces. +1. définir les permissions sur les ressources à l'échelle du cluster + +Si vous souhaitez définir un rôle au sein d'un namespace, utilisez un Role; si vous souhaitez +définir un rôle à l'échelle du cluster, utilisez un ClusterRole. +#### Role example + +Voici un exemple de rôle dans le namespace "default" qui peut être utilisé pour accorder un accès en lecture aux +{{< glossary_tooltip text="pods" term_id="pod" >}}: + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: Role +metadata: + namespace: default + name: pod-reader +rules: +- apiGroups: [""] # "" indicates the core API group + resources: ["pods"] + verbs: ["get", "watch", "list"] +``` + +#### ClusterRole example + +Une ClusterRole peut être utilisée pour accorder les mêmes permissions qu'un rôle. +Étant donné que les ClusterRoles sont à l'échelle des clusters, vous pouvez également +les utiliser pour accorder l'accès à : + +* des ressources à l'échelle du cluster (comme {{< glossary_tooltip text="nodes" term_id="node" >}}) +* des endpoints non liés aux ressources (comme `/healthz`) +* des ressources à namespaces (comme les pods), dans tous les namespaces. + + Par exemple : vous pouvez utiliser un ClusterRole pour autoriser un utilisateur particulier à exécuter + `kubectl get pods --all-namespaces` + +Voici un exemple de ClusterRole qui peut être utilisé pour accorder un accès en lecture à +{{< glossary_tooltip text="secrets" term_id="secret" >}} dans un namespace particulier, +ou dans tous les namespaces (selon la façon dont il est [lié](#rolebinding-and-clusterrolebinding)) : + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + # "namespace" omitted since ClusterRoles are not namespaced + name: secret-reader +rules: +- apiGroups: [""] + # + # at the HTTP level, the name of the resource for accessing Secret + # objects is "secrets" + resources: ["secrets"] + verbs: ["get", "watch", "list"] +``` + +Le nom d'un Role ou d'un objet ClusterRole doit être un +[nom de segment de chemin](/docs/concepts/overview/working-with-objects/names#path-segment-names) valide. + +### RoleBinding et ClusterRoleBinding + +Un RoleBinding accorde les permissions définies dans un rôle à un utilisateur ou à un ensemble d'utilisateurs. +Il contient une liste de *sujets* (utilisateurs, groupes, ou comptes de service), et une référence au rôle accordé. +Un RoleBinding accorde des permissions dans un namespace spécifique alors qu'un ClusterRoleBinding accorde cet accès à l'échelle du cluster. + +Le nom d'un objet RoleBinding ou ClusterRoleBinding doit être un [nom de segment de chemin](/docs/concepts/overview/working-with-objects/names#path-segment-names) valide. + +#### Exemples de RoleBinding {#rolebinding-example} + +Voici un exemple de RoleBinding qui accorde le Role "pod-reader" à l'utilisateur "jane" +dans le namespace "default". +Ceci permet à "jane" de lire les pods dans le namespace "default". + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +# This role binding allows "jane" to read pods in the "default" namespace. +# You need to already have a Role named "pod-reader" in that namespace. +kind: RoleBinding +metadata: + name: read-pods + namespace: default +subjects: +# You can specify more than one "subject" +- kind: User + name: jane # "name" is case sensitive + apiGroup: rbac.authorization.k8s.io +roleRef: + # "roleRef" specifies the binding to a Role / ClusterRole + kind: Role #this must be Role or ClusterRole + name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to + apiGroup: rbac.authorization.k8s.io +``` + +Un RoleBinding peut également faire référence à un ClusterRole pour accorder les +permissions définies dans ce ClusterRole aux ressources du namespace du RoleBinding. +Ce type de référence vous permet de définir un ensemble de rôles communs à l'ensemble +de votre cluster, puis de les réutiliser dans plusieurs namespaces. + +Par exemple, même si le RoleBinding suivant fait référence à un ClusterRole, "dave" (le sujet, sensible à la casse) +ne pourra lire que les Secrets dans le namespace "development", car le namespace du +RoleBinding (dans son metadata) est "development". + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +# This role binding allows "dave" to read secrets in the "development" namespace. +# You need to already have a ClusterRole named "secret-reader". +kind: RoleBinding +metadata: + name: read-secrets + # + # The namespace of the RoleBinding determines where the permissions are granted. + # This only grants permissions within the "development" namespace. + namespace: development +subjects: +- kind: User + name: dave # Name is case sensitive + apiGroup: rbac.authorization.k8s.io +roleRef: + kind: ClusterRole + name: secret-reader + apiGroup: rbac.authorization.k8s.io +``` + +#### Exemple de ClusterRoleBinding + +Pour accorder des permissions sur l'ensemble d'un cluster, vous pouvez utiliser un +ClusterRoleBinding. Le ClusterRoleBinding suivant permet à tout utilisateur du groupe "manager" +de lire secrets dans n'importe quel namespace. + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace. +kind: ClusterRoleBinding +metadata: + name: read-secrets-global +subjects: +- kind: Group + name: manager # Name is case sensitive + apiGroup: rbac.authorization.k8s.io +roleRef: + kind: ClusterRole + name: secret-reader + apiGroup: rbac.authorization.k8s.io +``` + +After you create a binding, you cannot change the Role or ClusterRole that it refers to. +If you try to change a binding's `roleRef`, you get a validation error. If you do want +to change the `roleRef` for a binding, you need to remove the binding object and create +a replacement. + +There are two reasons for this restriction: + +1. Making `roleRef` immutable allows granting someone `update` permission on an existing binding +object, so that they can manage the list of subjects, without being able to change +the role that is granted to those subjects. +1. A binding to a different role is a fundamentally different binding. +Requiring a binding to be deleted/recreated in order to change the `roleRef` +ensures the full list of subjects in the binding is intended to be granted +the new role (as opposed to enabling or accidentally modifying only the roleRef +without verifying all of the existing subjects should be given the new role's +permissions). + +The `kubectl auth reconcile` command-line utility creates or updates a manifest file containing RBAC objects, +and handles deleting and recreating binding objects if required to change the role they refer to. +See [command usage and examples](#kubectl-auth-reconcile) for more information. + +### Referring to resources + +In the Kubernetes API, most resources are represented and accessed using a string representation of +their object name, such as `pods` for a Pod. RBAC refers to resources using exactly the same +name that appears in the URL for the relevant API endpoint. +Some Kubernetes APIs involve a +_subresource_, such as the logs for a Pod. A request for a Pod's logs looks like: + +```http +GET /api/v1/namespaces/{namespace}/pods/{name}/log +``` + +In this case, `pods` is the namespaced resource for Pod resources, and `log` is a +subresource of `pods`. To represent this in an RBAC role, use a slash (`/`) to +delimit the resource and subresource. To allow a subject to read `pods` and +also access the `log` subresource for each of those Pods, you write: + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: Role +metadata: + namespace: default + name: pod-and-pod-logs-reader +rules: +- apiGroups: [""] + resources: ["pods", "pods/log"] + verbs: ["get", "list"] +``` + +You can also refer to resources by name for certain requests through the `resourceNames` list. +When specified, requests can be restricted to individual instances of a resource. +Here is an example that restricts its subject to only `get` or `update` a +{{< glossary_tooltip term_id="ConfigMap" >}} named `my-configmap`: + + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: Role +metadata: + namespace: default + name: configmap-updater +rules: +- apiGroups: [""] + # + # at the HTTP level, the name of the resource for accessing ConfigMap + # objects is "configmaps" + resources: ["configmaps"] + resourceNames: ["my-configmap"] + verbs: ["update", "get"] +``` + +{{< note >}} +You cannot restrict `create` or `deletecollection` requests by their resource name. +For `create`, this limitation is because the name of the new object may not be known at authorization time. +If you restrict `list` or `watch` by resourceName, clients must include a `metadata.name` field selector in their `list` or `watch` request that matches the specified resourceName in order to be authorized. +For example, `kubectl get configmaps --field-selector=metadata.name=my-configmap` +{{< /note >}} + +Rather than referring to individual `resources` and `verbs` you can use the wildcard `*` symbol to refer to all such objects. +For `nonResourceURLs` you can use the wildcard `*` symbol as a suffix glob match and for `apiGroups` and `resourceNames` an empty set means that everything is allowed. +Here is an example that allows access to perform any current and future action on all current and future resources (note, this is similar to the built-in `cluster-admin` role). + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: Role +metadata: + namespace: default + name: example.com-superuser # DO NOT USE THIS ROLE, IT IS JUST AN EXAMPLE +rules: +- apiGroups: ["example.com"] + resources: ["*"] + verbs: ["*"] +``` + +{{< caution >}} +Using wildcards in resource and verb entries could result in overly permissive access being granted to sensitive resources. +For instance, if a new resource type is added, or a new subresource is added, or a new custom verb is checked, the wildcard entry automatically grants access, which may be undesirable. +The [principle of least privilege](/docs/concepts/security/rbac-good-practices/#least-privilege) should be employed, using specific resources and verbs to ensure only the permissions required for the workload to function correctly are applied. +{{< /caution >}} + + +### Aggregated ClusterRoles + +You can _aggregate_ several ClusterRoles into one combined ClusterRole. +A controller, running as part of the cluster control plane, watches for ClusterRole +objects with an `aggregationRule` set. The `aggregationRule` defines a label +{{< glossary_tooltip text="selector" term_id="selector" >}} that the controller +uses to match other ClusterRole objects that should be combined into the `rules` +field of this one. + +{{< caution >}} +The control plane overwrites any values that you manually specify in the `rules` field of an +aggregate ClusterRole. If you want to change or add rules, do so in the `ClusterRole` objects +that are selected by the `aggregationRule`. +{{< /caution >}} + +Here is an example aggregated ClusterRole: + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: monitoring +aggregationRule: + clusterRoleSelectors: + - matchLabels: + rbac.example.com/aggregate-to-monitoring: "true" +rules: [] # The control plane automatically fills in the rules +``` + +If you create a new ClusterRole that matches the label selector of an existing aggregated ClusterRole, +that change triggers adding the new rules into the aggregated ClusterRole. +Here is an example that adds rules to the "monitoring" ClusterRole, by creating another +ClusterRole labeled `rbac.example.com/aggregate-to-monitoring: true`. + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: monitoring-endpoints + labels: + rbac.example.com/aggregate-to-monitoring: "true" +# When you create the "monitoring-endpoints" ClusterRole, +# the rules below will be added to the "monitoring" ClusterRole. +rules: +- apiGroups: [""] + resources: ["services", "endpointslices", "pods"] + verbs: ["get", "list", "watch"] +``` + +The [default user-facing roles](#default-roles-and-role-bindings) use ClusterRole aggregation. This lets you, +as a cluster administrator, include rules for custom resources, such as those served by +{{< glossary_tooltip term_id="CustomResourceDefinition" text="CustomResourceDefinitions" >}} +or aggregated API servers, to extend the default roles. + +For example: the following ClusterRoles let the "admin" and "edit" default roles manage the custom resource +named CronTab, whereas the "view" role can perform only read actions on CronTab resources. +You can assume that CronTab objects are named `"crontabs"` in URLs as seen by the API server. + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: aggregate-cron-tabs-edit + labels: + # Add these permissions to the "admin" and "edit" default roles. + rbac.authorization.k8s.io/aggregate-to-admin: "true" + rbac.authorization.k8s.io/aggregate-to-edit: "true" +rules: +- apiGroups: ["stable.example.com"] + resources: ["crontabs"] + verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] +--- +kind: ClusterRole +apiVersion: rbac.authorization.k8s.io/v1 +metadata: + name: aggregate-cron-tabs-view + labels: + # Add these permissions to the "view" default role. + rbac.authorization.k8s.io/aggregate-to-view: "true" +rules: +- apiGroups: ["stable.example.com"] + resources: ["crontabs"] + verbs: ["get", "list", "watch"] +``` + +#### Role examples + +The following examples are excerpts from Role or ClusterRole objects, showing only +the `rules` section. + +Allow reading `"pods"` resources in the core +{{< glossary_tooltip text="API Group" term_id="api-group" >}}: + +```yaml +rules: +- apiGroups: [""] + # + # at the HTTP level, the name of the resource for accessing Pod + # objects is "pods" + resources: ["pods"] + verbs: ["get", "list", "watch"] +``` + +Allow reading/writing Deployments (at the HTTP level: objects with `"deployments"` +in the resource part of their URL) in the `"apps"` API groups: + +```yaml +rules: +- apiGroups: ["apps"] + # + # at the HTTP level, the name of the resource for accessing Deployment + # objects is "deployments" + resources: ["deployments"] + verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] +``` + +Allow reading Pods in the core API group, as well as reading or writing Job +resources in the `"batch"` API group: + +```yaml +rules: +- apiGroups: [""] + # + # at the HTTP level, the name of the resource for accessing Pod + # objects is "pods" + resources: ["pods"] + verbs: ["get", "list", "watch"] +- apiGroups: ["batch"] + # + # at the HTTP level, the name of the resource for accessing Job + # objects is "jobs" + resources: ["jobs"] + verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] +``` + +Allow reading a ConfigMap named "my-config" (must be bound with a +RoleBinding to limit to a single ConfigMap in a single namespace): + +```yaml +rules: +- apiGroups: [""] + # + # at the HTTP level, the name of the resource for accessing ConfigMap + # objects is "configmaps" + resources: ["configmaps"] + resourceNames: ["my-config"] + verbs: ["get"] +``` + +Allow reading the resource `"nodes"` in the core group (because a +Node is cluster-scoped, this must be in a ClusterRole bound with a +ClusterRoleBinding to be effective): + +```yaml +rules: +- apiGroups: [""] + # + # at the HTTP level, the name of the resource for accessing Node + # objects is "nodes" + resources: ["nodes"] + verbs: ["get", "list", "watch"] +``` + +Allow GET and POST requests to the non-resource endpoint `/healthz` and +all subpaths (must be in a ClusterRole bound with a ClusterRoleBinding +to be effective): + +```yaml +rules: +- nonResourceURLs: ["/healthz", "/healthz/*"] # '*' in a nonResourceURL is a suffix glob match + verbs: ["get", "post"] +``` + +### Referring to subjects + +A RoleBinding or ClusterRoleBinding binds a role to subjects. +Subjects can be groups, users or +{{< glossary_tooltip text="ServiceAccounts" term_id="service-account" >}}. + +Kubernetes represents usernames as strings. +These can be: plain names, such as "alice"; email-style names, like "bob@example.com"; +or numeric user IDs represented as a string. It is up to you as a cluster administrator +to configure the [authentication modules](/docs/reference/access-authn-authz/authentication/) +so that authentication produces usernames in the format you want. + +{{< caution >}} +The prefix `system:` is reserved for Kubernetes system use, so you should ensure +that you don't have users or groups with names that start with `system:` by +accident. +Other than this special prefix, the RBAC authorization system does not require any format +for usernames. +{{< /caution >}} + +In Kubernetes, Authenticator modules provide group information. +Groups, like users, are represented as strings, and that string has no format requirements, +other than that the prefix `system:` is reserved. + +[ServiceAccounts](/docs/tasks/configure-pod-container/configure-service-account/) have names prefixed +with `system:serviceaccount:`, and belong to groups that have names prefixed with `system:serviceaccounts:`. + +{{< note >}} +- `system:serviceaccount:` (singular) is the prefix for service account usernames. +- `system:serviceaccounts:` (plural) is the prefix for service account groups. +{{< /note >}} + +#### RoleBinding examples {#role-binding-examples} + +The following examples are `RoleBinding` excerpts that only +show the `subjects` section. + +For a user named `alice@example.com`: + +```yaml +subjects: +- kind: User + name: "alice@example.com" + apiGroup: rbac.authorization.k8s.io +``` + +For a group named `frontend-admins`: + +```yaml +subjects: +- kind: Group + name: "frontend-admins" + apiGroup: rbac.authorization.k8s.io +``` + +For the default service account in the "kube-system" namespace: + +```yaml +subjects: +- kind: ServiceAccount + name: default + namespace: kube-system +``` + +For all service accounts in the "qa" namespace: + +```yaml +subjects: +- kind: Group + name: system:serviceaccounts:qa + apiGroup: rbac.authorization.k8s.io +``` + +For all service accounts in any namespace: + +```yaml +subjects: +- kind: Group + name: system:serviceaccounts + apiGroup: rbac.authorization.k8s.io +``` + +For all authenticated users: + +```yaml +subjects: +- kind: Group + name: system:authenticated + apiGroup: rbac.authorization.k8s.io +``` + +For all unauthenticated users: + +```yaml +subjects: +- kind: Group + name: system:unauthenticated + apiGroup: rbac.authorization.k8s.io +``` + +For all users: + +```yaml +subjects: +- kind: Group + name: system:authenticated + apiGroup: rbac.authorization.k8s.io +- kind: Group + name: system:unauthenticated + apiGroup: rbac.authorization.k8s.io +``` + +## Default roles and role bindings + +API servers create a set of default ClusterRole and ClusterRoleBinding objects. +Many of these are `system:` prefixed, which indicates that the resource is directly +managed by the cluster control plane. +All of the default ClusterRoles and ClusterRoleBindings are labeled with `kubernetes.io/bootstrapping=rbac-defaults`. + +{{< caution >}} +Take care when modifying ClusterRoles and ClusterRoleBindings with names +that have a `system:` prefix. +Modifications to these resources can result in non-functional clusters. +{{< /caution >}} + +### Auto-reconciliation + +At each start-up, the API server updates default cluster roles with any missing permissions, +and updates default cluster role bindings with any missing subjects. +This allows the cluster to repair accidental modifications, and helps to keep roles and role bindings +up-to-date as permissions and subjects change in new Kubernetes releases. + +To opt out of this reconciliation, set the `rbac.authorization.kubernetes.io/autoupdate` +annotation on a default cluster role or rolebinding to `false`. +Be aware that missing default permissions and subjects can result in non-functional clusters. + +Auto-reconciliation is enabled by default if the RBAC authorizer is active. + +### API discovery roles {#discovery-roles} + +Default role bindings authorize unauthenticated and authenticated users to read API information that is deemed safe to be publicly accessible (including CustomResourceDefinitions). To disable anonymous unauthenticated access, add `--anonymous-auth=false` to the API server configuration. + +To view the configuration of these roles via `kubectl` run: + +```shell +kubectl get clusterroles system:discovery -o yaml +``` + +{{< note >}} +If you edit that ClusterRole, your changes will be overwritten on API server restart +via [auto-reconciliation](#auto-reconciliation). To avoid that overwriting, +either do not manually edit the role, or disable auto-reconciliation. +{{< /note >}} + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Kubernetes RBAC API discovery roles
Default ClusterRoleDefault ClusterRoleBindingDescription
system:basic-usersystem:authenticated groupAllows a user read-only access to basic information about themselves. Prior to v1.14, this role was also bound to system:unauthenticated by default.
system:discoverysystem:authenticated groupAllows read-only access to API discovery endpoints needed to discover and negotiate an API level. Prior to v1.14, this role was also bound to system:unauthenticated by default.
system:public-info-viewersystem:authenticated and system:unauthenticated groupsAllows read-only access to non-sensitive information about the cluster. Introduced in Kubernetes v1.14.
+ +### User-facing roles + +Some of the default ClusterRoles are not `system:` prefixed. These are intended to be user-facing roles. +They include super-user roles (`cluster-admin`), roles intended to be granted cluster-wide +using ClusterRoleBindings, and roles intended to be granted within particular +namespaces using RoleBindings (`admin`, `edit`, `view`). + +User-facing ClusterRoles use [ClusterRole aggregation](#aggregated-clusterroles) to allow admins to include +rules for custom resources on these ClusterRoles. To add rules to the `admin`, `edit`, or `view` roles, create +a ClusterRole with one or more of the following labels: + +```yaml +metadata: + labels: + rbac.authorization.k8s.io/aggregate-to-admin: "true" + rbac.authorization.k8s.io/aggregate-to-edit: "true" + rbac.authorization.k8s.io/aggregate-to-view: "true" +``` + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Default ClusterRoleDefault ClusterRoleBindingDescription
cluster-adminsystem:masters groupAllows super-user access to perform any action on any resource. +When used in a ClusterRoleBinding, it gives full control over every resource in the cluster and in all namespaces. +When used in a RoleBinding, it gives full control over every resource in the role binding's namespace, including the namespace itself.
adminNoneAllows admin access, intended to be granted within a namespace using a RoleBinding. + +If used in a RoleBinding, allows read/write access to most resources in a namespace, +including the ability to create roles and role bindings within the namespace. +This role does not allow write access to resource quota or to the namespace itself. +This role also does not allow write access to EndpointSlices (or Endpoints) in clusters created +using Kubernetes v1.22+. More information is available in the +["Write Access for EndpointSlices and Endpoints" section](#write-access-for-endpoints).
editNoneAllows read/write access to most objects in a namespace. + +This role does not allow viewing or modifying roles or role bindings. +However, this role allows accessing Secrets and running Pods as any ServiceAccount in +the namespace, so it can be used to gain the API access levels of any ServiceAccount in +the namespace. This role also does not allow write access to EndpointSlices (or Endpoints) in +clusters created using Kubernetes v1.22+. More information is available in the +["Write Access for EndpointSlices and Endpoints" section](#write-access-for-endpoints).
viewNoneAllows read-only access to see most objects in a namespace. +It does not allow viewing roles or role bindings. + +This role does not allow viewing Secrets, since reading +the contents of Secrets enables access to ServiceAccount credentials +in the namespace, which would allow API access as any ServiceAccount +in the namespace (a form of privilege escalation).
+ +### Core component roles + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Default ClusterRoleDefault ClusterRoleBindingDescription
system:kube-schedulersystem:kube-scheduler userAllows access to the resources required by the {{< glossary_tooltip term_id="kube-scheduler" text="scheduler" >}} component.
system:volume-schedulersystem:kube-scheduler userAllows access to the volume resources required by the kube-scheduler component.
system:kube-controller-managersystem:kube-controller-manager userAllows access to the resources required by the {{< glossary_tooltip term_id="kube-controller-manager" text="controller manager" >}} component. +The permissions required by individual controllers are detailed in the controller roles.
system:nodeNoneAllows access to resources required by the kubelet, including read access to all secrets, and write access to all pod status objects. + +You should use the Node authorizer and NodeRestriction admission plugin instead of the system:node role, and allow granting API access to kubelets based on the Pods scheduled to run on them. + +The system:node role only exists for compatibility with Kubernetes clusters upgraded from versions prior to v1.8. +
system:node-proxiersystem:kube-proxy userAllows access to the resources required by the {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}} component.
+ +### Other component roles + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Default ClusterRoleDefault ClusterRoleBindingDescription
system:auth-delegatorNoneAllows delegated authentication and authorization checks. +This is commonly used by add-on API servers for unified authentication and authorization.
system:heapsterNoneRole for the Heapster component (deprecated).
system:kube-aggregatorNoneRole for the kube-aggregator component.
system:kube-dnskube-dns service account in the kube-system namespaceRole for the kube-dns component.
system:kubelet-api-adminNoneAllows full access to the kubelet API.
system:node-bootstrapperNoneAllows access to the resources required to perform +kubelet TLS bootstrapping.
system:node-problem-detectorNoneRole for the node-problem-detector component.
system:persistent-volume-provisionerNoneAllows access to the resources required by most dynamic volume provisioners.
system:monitoringsystem:monitoring groupAllows read access to control-plane monitoring endpoints (i.e. {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} liveness and readiness endpoints (/healthz, /livez, /readyz), the individual health-check endpoints (/healthz/*, /livez/*, /readyz/*), and /metrics). Note that individual health check endpoints and the metric endpoint may expose sensitive information.
+ +### Roles for built-in controllers {#controller-roles} + +The Kubernetes {{< glossary_tooltip term_id="kube-controller-manager" text="controller manager" >}} runs +{{< glossary_tooltip term_id="controller" text="controllers" >}} that are built in to the Kubernetes +control plane. +When invoked with `--use-service-account-credentials`, kube-controller-manager starts each controller +using a separate service account. +Corresponding roles exist for each built-in controller, prefixed with `system:controller:`. +If the controller manager is not started with `--use-service-account-credentials`, it runs all control loops +using its own credential, which must be granted all the relevant roles. +These roles include: + +* `system:controller:attachdetach-controller` +* `system:controller:certificate-controller` +* `system:controller:clusterrole-aggregation-controller` +* `system:controller:cronjob-controller` +* `system:controller:daemon-set-controller` +* `system:controller:deployment-controller` +* `system:controller:disruption-controller` +* `system:controller:endpoint-controller` +* `system:controller:expand-controller` +* `system:controller:generic-garbage-collector` +* `system:controller:horizontal-pod-autoscaler` +* `system:controller:job-controller` +* `system:controller:namespace-controller` +* `system:controller:node-controller` +* `system:controller:persistent-volume-binder` +* `system:controller:pod-garbage-collector` +* `system:controller:pv-protection-controller` +* `system:controller:pvc-protection-controller` +* `system:controller:replicaset-controller` +* `system:controller:replication-controller` +* `system:controller:resourcequota-controller` +* `system:controller:root-ca-cert-publisher` +* `system:controller:route-controller` +* `system:controller:service-account-controller` +* `system:controller:service-controller` +* `system:controller:statefulset-controller` +* `system:controller:ttl-controller` + +## Privilege escalation prevention and bootstrapping + +The RBAC API prevents users from escalating privileges by editing roles or role bindings. +Because this is enforced at the API level, it applies even when the RBAC authorizer is not in use. + +### Restrictions on role creation or update + +You can only create/update a role if at least one of the following things is true: + +1. You already have all the permissions contained in the role, at the same scope as the object being modified +(cluster-wide for a ClusterRole, within the same namespace or cluster-wide for a Role). +2. You are granted explicit permission to perform the `escalate` verb on the `roles` or `clusterroles` resource in the `rbac.authorization.k8s.io` API group. + +For example, if `user-1` does not have the ability to list Secrets cluster-wide, they cannot create a ClusterRole +containing that permission. To allow a user to create/update roles: + +1. Grant them a role that allows them to create/update Role or ClusterRole objects, as desired. +2. Grant them permission to include specific permissions in the roles they create/update: + * implicitly, by giving them those permissions (if they attempt to create or modify a Role or ClusterRole with permissions they themselves have not been granted, the API request will be forbidden) + * or explicitly allow specifying any permission in a `Role` or `ClusterRole` by giving them permission to perform the `escalate` verb on `roles` or `clusterroles` resources in the `rbac.authorization.k8s.io` API group + +### Restrictions on role binding creation or update + +You can only create/update a role binding if you already have all the permissions contained in the referenced role +(at the same scope as the role binding) *or* if you have been authorized to perform the `bind` verb on the referenced role. +For example, if `user-1` does not have the ability to list Secrets cluster-wide, they cannot create a ClusterRoleBinding +to a role that grants that permission. To allow a user to create/update role bindings: + +1. Grant them a role that allows them to create/update RoleBinding or ClusterRoleBinding objects, as desired. +2. Grant them permissions needed to bind a particular role: + * implicitly, by giving them the permissions contained in the role. + * explicitly, by giving them permission to perform the `bind` verb on the particular Role (or ClusterRole). + +For example, this ClusterRole and RoleBinding would allow `user-1` to grant other users the `admin`, `edit`, and `view` roles in the namespace `user-1-namespace`: + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: role-grantor +rules: +- apiGroups: ["rbac.authorization.k8s.io"] + resources: ["rolebindings"] + verbs: ["create"] +- apiGroups: ["rbac.authorization.k8s.io"] + resources: ["clusterroles"] + verbs: ["bind"] + # omit resourceNames to allow binding any ClusterRole + resourceNames: ["admin","edit","view"] +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: RoleBinding +metadata: + name: role-grantor-binding + namespace: user-1-namespace +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: role-grantor +subjects: +- apiGroup: rbac.authorization.k8s.io + kind: User + name: user-1 +``` + +When bootstrapping the first roles and role bindings, it is necessary for the initial user to grant permissions they do not yet have. +To bootstrap initial roles and role bindings: + +* Use a credential with the "system:masters" group, which is bound to the "cluster-admin" super-user role by the default bindings. + +## Command-line utilities + +### `kubectl create role` + +Creates a Role object defining permissions within a single namespace. Examples: + +* Create a Role named "pod-reader" that allows users to perform `get`, `watch` and `list` on pods: + + ```shell + kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods + ``` + +* Create a Role named "pod-reader" with resourceNames specified: + + ```shell + kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod + ``` + +* Create a Role named "foo" with apiGroups specified: + + ```shell + kubectl create role foo --verb=get,list,watch --resource=replicasets.apps + ``` + +* Create a Role named "foo" with subresource permissions: + + ```shell + kubectl create role foo --verb=get,list,watch --resource=pods,pods/status + ``` + +* Create a Role named "my-component-lease-holder" with permissions to get/update a resource with a specific name: + + ```shell + kubectl create role my-component-lease-holder --verb=get,list,watch,update --resource=lease --resource-name=my-component + ``` + +### `kubectl create clusterrole` + +Creates a ClusterRole. Examples: + +* Create a ClusterRole named "pod-reader" that allows user to perform `get`, `watch` and `list` on pods: + + ```shell + kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods + ``` + +* Create a ClusterRole named "pod-reader" with resourceNames specified: + + ```shell + kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod + ``` + +* Create a ClusterRole named "foo" with apiGroups specified: + + ```shell + kubectl create clusterrole foo --verb=get,list,watch --resource=replicasets.apps + ``` + +* Create a ClusterRole named "foo" with subresource permissions: + + ```shell + kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status + ``` + +* Create a ClusterRole named "foo" with nonResourceURL specified: + + ```shell + kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/* + ``` + +* Create a ClusterRole named "monitoring" with an aggregationRule specified: + + ```shell + kubectl create clusterrole monitoring --aggregation-rule="rbac.example.com/aggregate-to-monitoring=true" + ``` + +### `kubectl create rolebinding` + +Grants a Role or ClusterRole within a specific namespace. Examples: + +* Within the namespace "acme", grant the permissions in the "admin" ClusterRole to a user named "bob": + + ```shell + kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme + ``` + +* Within the namespace "acme", grant the permissions in the "view" ClusterRole to the service account in the namespace "acme" named "myapp": + + ```shell + kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme + ``` + +* Within the namespace "acme", grant the permissions in the "view" ClusterRole to a service account in the namespace "myappnamespace" named "myapp": + + ```shell + kubectl create rolebinding myappnamespace-myapp-view-binding --clusterrole=view --serviceaccount=myappnamespace:myapp --namespace=acme + ``` + +### `kubectl create clusterrolebinding` + +Grants a ClusterRole across the entire cluster (all namespaces). Examples: + +* Across the entire cluster, grant the permissions in the "cluster-admin" ClusterRole to a user named "root": + + ```shell + kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root + ``` + +* Across the entire cluster, grant the permissions in the "system:node-proxier" ClusterRole to a user named "system:kube-proxy": + + ```shell + kubectl create clusterrolebinding kube-proxy-binding --clusterrole=system:node-proxier --user=system:kube-proxy + ``` + +* Across the entire cluster, grant the permissions in the "view" ClusterRole to a service account named "myapp" in the namespace "acme": + + ```shell + kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp + ``` + +### `kubectl auth reconcile` {#kubectl-auth-reconcile} + +Creates or updates `rbac.authorization.k8s.io/v1` API objects from a manifest file. + +Missing objects are created, and the containing namespace is created for namespaced objects, if required. + +Existing roles are updated to include the permissions in the input objects, +and remove extra permissions if `--remove-extra-permissions` is specified. + +Existing bindings are updated to include the subjects in the input objects, +and remove extra subjects if `--remove-extra-subjects` is specified. + +Examples: + +* Test applying a manifest file of RBAC objects, displaying changes that would be made: + + ``` + kubectl auth reconcile -f my-rbac-rules.yaml --dry-run=client + ``` + +* Apply a manifest file of RBAC objects, preserving any extra permissions (in roles) and any extra subjects (in bindings): + + ```shell + kubectl auth reconcile -f my-rbac-rules.yaml + ``` + +* Apply a manifest file of RBAC objects, removing any extra permissions (in roles) and any extra subjects (in bindings): + + ```shell + kubectl auth reconcile -f my-rbac-rules.yaml --remove-extra-subjects --remove-extra-permissions + ``` + +## ServiceAccount permissions {#service-account-permissions} + +Default RBAC policies grant scoped permissions to control-plane components, nodes, +and controllers, but grant *no permissions* to service accounts outside the `kube-system` namespace +(beyond discovery permissions given to all authenticated users). + +This allows you to grant particular roles to particular ServiceAccounts as needed. +Fine-grained role bindings provide greater security, but require more effort to administrate. +Broader grants can give unnecessary (and potentially escalating) API access to +ServiceAccounts, but are easier to administrate. + +In order from most secure to least secure, the approaches are: + +1. Grant a role to an application-specific service account (best practice) + + This requires the application to specify a `serviceAccountName` in its pod spec, + and for the service account to be created (via the API, application manifest, `kubectl create serviceaccount`, etc.). + + For example, grant read-only permission within "my-namespace" to the "my-sa" service account: + + ```shell + kubectl create rolebinding my-sa-view \ + --clusterrole=view \ + --serviceaccount=my-namespace:my-sa \ + --namespace=my-namespace + ``` + +2. Grant a role to the "default" service account in a namespace + + If an application does not specify a `serviceAccountName`, it uses the "default" service account. + + {{< note >}} + Permissions given to the "default" service account are available to any pod + in the namespace that does not specify a `serviceAccountName`. + {{< /note >}} + + For example, grant read-only permission within "my-namespace" to the "default" service account: + + ```shell + kubectl create rolebinding default-view \ + --clusterrole=view \ + --serviceaccount=my-namespace:default \ + --namespace=my-namespace + ``` + + Many [add-ons](/docs/concepts/cluster-administration/addons/) run as the + "default" service account in the `kube-system` namespace. + To allow those add-ons to run with super-user access, grant cluster-admin + permissions to the "default" service account in the `kube-system` namespace. + + {{< caution >}} + Enabling this means the `kube-system` namespace contains Secrets + that grant super-user access to your cluster's API. + {{< /caution >}} + + ```shell + kubectl create clusterrolebinding add-on-cluster-admin \ + --clusterrole=cluster-admin \ + --serviceaccount=kube-system:default + ``` + +3. Grant a role to all service accounts in a namespace + + If you want all applications in a namespace to have a role, no matter what service account they use, + you can grant a role to the service account group for that namespace. + + For example, grant read-only permission within "my-namespace" to all service accounts in that namespace: + + ```shell + kubectl create rolebinding serviceaccounts-view \ + --clusterrole=view \ + --group=system:serviceaccounts:my-namespace \ + --namespace=my-namespace + ``` + +4. Grant a limited role to all service accounts cluster-wide (discouraged) + + If you don't want to manage permissions per-namespace, you can grant a cluster-wide role to all service accounts. + + For example, grant read-only permission across all namespaces to all service accounts in the cluster: + + ```shell + kubectl create clusterrolebinding serviceaccounts-view \ + --clusterrole=view \ + --group=system:serviceaccounts + ``` + +5. Grant super-user access to all service accounts cluster-wide (strongly discouraged) + + If you don't care about partitioning permissions at all, you can grant super-user access to all service accounts. + + {{< warning >}} + This allows any application full access to your cluster, and also grants + any user with read access to Secrets (or the ability to create any pod) + full access to your cluster. + {{< /warning >}} + + ```shell + kubectl create clusterrolebinding serviceaccounts-cluster-admin \ + --clusterrole=cluster-admin \ + --group=system:serviceaccounts + ``` + +## Write access for EndpointSlices and Endpoints {#write-access-for-endpoints} + +Kubernetes clusters created before Kubernetes v1.22 include write access to +EndpointSlices (and Endpoints) in the aggregated "edit" and "admin" roles. +As a mitigation for [CVE-2021-25740](https://github.com/kubernetes/kubernetes/issues/103675), +this access is not part of the aggregated roles in clusters that you create using +Kubernetes v1.22 or later. + +Existing clusters that have been upgraded to Kubernetes v1.22 will not be +subject to this change. The [CVE +announcement](https://github.com/kubernetes/kubernetes/issues/103675) includes +guidance for restricting this access in existing clusters. + +If you want new clusters to retain this level of access in the aggregated roles, +you can create the following ClusterRole: + +{{< codenew file="access/endpoints-aggregated.yaml" >}} + +## Upgrading from ABAC + +Clusters that originally ran older Kubernetes versions often used +permissive ABAC policies, including granting full API access to all +service accounts. + +Default RBAC policies grant scoped permissions to control-plane components, nodes, +and controllers, but grant *no permissions* to service accounts outside the `kube-system` namespace +(beyond discovery permissions given to all authenticated users). + +While far more secure, this can be disruptive to existing workloads expecting to automatically receive API permissions. +Here are two approaches for managing this transition: + +### Parallel authorizers + +Run both the RBAC and ABAC authorizers, and specify a policy file that contains +the [legacy ABAC policy](/docs/reference/access-authn-authz/abac/#policy-file-format): + +``` +--authorization-mode=...,RBAC,ABAC --authorization-policy-file=mypolicy.json +``` + +To explain that first command line option in detail: if earlier authorizers, such as Node, +deny a request, then the RBAC authorizer attempts to authorize the API request. If RBAC +also denies that API request, the ABAC authorizer is then run. This means that any request +allowed by *either* the RBAC or ABAC policies is allowed. + +When the kube-apiserver is run with a log level of 5 or higher for the RBAC component +(`--vmodule=rbac*=5` or `--v=5`), you can see RBAC denials in the API server log +(prefixed with `RBAC`). +You can use that information to determine which roles need to be granted to which users, groups, or service accounts. + +Once you have [granted roles to service accounts](#service-account-permissions) and workloads +are running with no RBAC denial messages in the server logs, you can remove the ABAC authorizer. + +### Permissive RBAC permissions + +You can replicate a permissive ABAC policy using RBAC role bindings. + +{{< warning >}} +The following policy allows **ALL** service accounts to act as cluster administrators. +Any application running in a container receives service account credentials automatically, +and could perform any action against the API, including viewing secrets and modifying permissions. +This is not a recommended policy. + +```shell +kubectl create clusterrolebinding permissive-binding \ + --clusterrole=cluster-admin \ + --user=admin \ + --user=kubelet \ + --group=system:serviceaccounts +``` +{{< /warning >}} + +After you have transitioned to use RBAC, you should adjust the access controls +for your cluster to ensure that these meet your information security needs. From 5ae6a790bba42031c79f5287773f35a232c41366 Mon Sep 17 00:00:00 2001 From: vincent Date: Mon, 23 Jan 2023 21:31:40 +0000 Subject: [PATCH 02/14] Translate rbac documenttaion in french --- .../docs/reference/access-authn-authz/rbac.md | 38 ++++++++++--------- 1 file changed, 20 insertions(+), 18 deletions(-) diff --git a/content/fr/docs/reference/access-authn-authz/rbac.md b/content/fr/docs/reference/access-authn-authz/rbac.md index cbffa267bcf..7689741d49f 100644 --- a/content/fr/docs/reference/access-authn-authz/rbac.md +++ b/content/fr/docs/reference/access-authn-authz/rbac.md @@ -212,34 +212,36 @@ roleRef: apiGroup: rbac.authorization.k8s.io ``` -After you create a binding, you cannot change the Role or ClusterRole that it refers to. -If you try to change a binding's `roleRef`, you get a validation error. If you do want -to change the `roleRef` for a binding, you need to remove the binding object and create -a replacement. +Après avoir créé un lien, vous ne pouvez pas modifier le Role ou le ClusterRole auquel il fait référence. +Si vous essayez de modifier le `roleRef` d'un lien, vous obtenez une erreur de validation. +Si vous souhaitez changer le `roleRef` d'un lien, vous devez supprimer l'objet binding +et en créer un autre. -There are two reasons for this restriction: +Il y a deux raisons à cette restriction : -1. Making `roleRef` immutable allows granting someone `update` permission on an existing binding -object, so that they can manage the list of subjects, without being able to change -the role that is granted to those subjects. -1. A binding to a different role is a fundamentally different binding. -Requiring a binding to be deleted/recreated in order to change the `roleRef` -ensures the full list of subjects in the binding is intended to be granted -the new role (as opposed to enabling or accidentally modifying only the roleRef -without verifying all of the existing subjects should be given the new role's -permissions). +1. Rendre `roleRef` immuable permet d'accorder à quelqu'un la permission `update` sur un objet de liaison existant, +afin qu'il puisse gérer la liste des sujets, sans pouvoir changer le rôle qui est accordé à ces sujets. +1. Un lien vers un rôle différent est un lien fondamentalement différent. +Le fait d'exiger qu'un lien soit supprimé/créé afin de modifier le `roleRef` +garantit que la liste complète des sujets dans le binding est destinée à +recevoir le nouveau rôle (par opposition à l'activation ou à la modification +accidentelle uniquement du roleRef sans vérifier que tous les sujets existants +doivent recevoir les permissions du nouveau rôle). -The `kubectl auth reconcile` command-line utility creates or updates a manifest file containing RBAC objects, -and handles deleting and recreating binding objects if required to change the role they refer to. -See [command usage and examples](#kubectl-auth-reconcile) for more information. +L'utilitaire de ligne de commande `kubectl auth reconcile` crée ou met à jour un fichier manifeste contenant des objets RBAC, +et gère la suppression et la recréation des objets de liaison si nécessaire pour modifier le rôle auquel ils se réfèrent. +Voir [utilisation de la commande et exemples](#kubectl-auth-reconcile) pour plus d'informations. -### Referring to resources +### Référence aux ressources In the Kubernetes API, most resources are represented and accessed using a string representation of their object name, such as `pods` for a Pod. RBAC refers to resources using exactly the same name that appears in the URL for the relevant API endpoint. Some Kubernetes APIs involve a _subresource_, such as the logs for a Pod. A request for a Pod's logs looks like: +Dans l'API Kubernetes, la plupart des ressources sont représentées et accessibles à l'aide d'une chaîne de caractères de leur nom d'objet, +comme `pods` pour un Pod. RBAC fait référence aux ressources en utilisant exactement le même nom que celui qui apparaît dans l'URL du point de terminaison de l'API concerné. +Certaines API Kubernetes impliquent une _sous-ressource_, comme les journaux d'un Pod. Une requête pour les journaux d'un Pod ressemble à ceci : ```http GET /api/v1/namespaces/{namespace}/pods/{name}/log From b48ce9d9c1444659d2def8f4d036c084973f15f1 Mon Sep 17 00:00:00 2001 From: vincent Date: Fri, 3 Feb 2023 22:24:12 +0000 Subject: [PATCH 03/14] Translate rbac/Referring to resources --- .../docs/reference/access-authn-authz/rbac.md | 48 +++++++++---------- 1 file changed, 22 insertions(+), 26 deletions(-) diff --git a/content/fr/docs/reference/access-authn-authz/rbac.md b/content/fr/docs/reference/access-authn-authz/rbac.md index 7689741d49f..c7af56ce881 100644 --- a/content/fr/docs/reference/access-authn-authz/rbac.md +++ b/content/fr/docs/reference/access-authn-authz/rbac.md @@ -234,23 +234,20 @@ Voir [utilisation de la commande et exemples](#kubectl-auth-reconcile) pour plus ### Référence aux ressources -In the Kubernetes API, most resources are represented and accessed using a string representation of -their object name, such as `pods` for a Pod. RBAC refers to resources using exactly the same -name that appears in the URL for the relevant API endpoint. -Some Kubernetes APIs involve a -_subresource_, such as the logs for a Pod. A request for a Pod's logs looks like: Dans l'API Kubernetes, la plupart des ressources sont représentées et accessibles à l'aide d'une chaîne de caractères de leur nom d'objet, -comme `pods` pour un Pod. RBAC fait référence aux ressources en utilisant exactement le même nom que celui qui apparaît dans l'URL du point de terminaison de l'API concerné. -Certaines API Kubernetes impliquent une _sous-ressource_, comme les journaux d'un Pod. Une requête pour les journaux d'un Pod ressemble à ceci : +comme `pods` pour un Pod. RBAC fait référence aux ressources en utilisant exactement +le même nom que celui qui apparaît dans l'URL du endpoint de l'API concerné. +Certaines API Kubernetes impliquent une +_subresource_, comme les logs d'un Pod. Une requête pour les logs d'un Pod ressemble à ceci : ```http GET /api/v1/namespaces/{namespace}/pods/{name}/log ``` -In this case, `pods` is the namespaced resource for Pod resources, and `log` is a -subresource of `pods`. To represent this in an RBAC role, use a slash (`/`) to -delimit the resource and subresource. To allow a subject to read `pods` and -also access the `log` subresource for each of those Pods, you write: +Dans ce cas, `pods` est le namespaced ressource pour les ressources Pods, +et `log` est une sous-ressource de `pods`. Pour représenter cela dans un rôle RBAC, +utilisez une barre oblique (`/`) pour délimiter la ressource et la sous-ressource. +Pour permettre à un sujet de lire `pods` et d'accéder également à la sous-ressource `log` pour chacun de ces Pods, vous écrivez : ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -264,11 +261,10 @@ rules: verbs: ["get", "list"] ``` -You can also refer to resources by name for certain requests through the `resourceNames` list. -When specified, requests can be restricted to individual instances of a resource. -Here is an example that restricts its subject to only `get` or `update` a -{{< glossary_tooltip term_id="ConfigMap" >}} named `my-configmap`: - +Vous pouvez également faire référence à des ressources par leur nom pour certaines demandes par le biais de la liste `resourceNames`. +Lorsque cela est spécifié, les demandes peuvent être limitées à des instances individuelles d'une ressource. +Voici un exemple qui limite son sujet seulement à `get` ou `update` une +{{< glossary_tooltip term_id="ConfigMap" >}} nommée `my-configmap`: ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -287,15 +283,15 @@ rules: ``` {{< note >}} -You cannot restrict `create` or `deletecollection` requests by their resource name. -For `create`, this limitation is because the name of the new object may not be known at authorization time. -If you restrict `list` or `watch` by resourceName, clients must include a `metadata.name` field selector in their `list` or `watch` request that matches the specified resourceName in order to be authorized. -For example, `kubectl get configmaps --field-selector=metadata.name=my-configmap` +Vous ne pouvez pas restreindre les demandes `create` ou `deletecollection` par leur nom de ressource. +Pour `create`, cette limitation est due au fait que le nom du nouvel objet peut ne pas être connu au moment de l'autorisation. +Si vous limitez `list` ou `watch` par le nom de la ressource, les clients doivent inclure un sélecteur de champ `metadata.name` dans leur demande de `list` ou `watch` qui correspond au nom de la ressource spécifiée afin d'être autorisés. +Par exemple, `kubectl get configmaps --field-selector=metadata.name=my-configmap` {{< /note >}} -Rather than referring to individual `resources` and `verbs` you can use the wildcard `*` symbol to refer to all such objects. -For `nonResourceURLs` you can use the wildcard `*` symbol as a suffix glob match and for `apiGroups` and `resourceNames` an empty set means that everything is allowed. -Here is an example that allows access to perform any current and future action on all current and future resources (note, this is similar to the built-in `cluster-admin` role). +Plutôt que de faire référence à des `ressources` et des `verbes` individuels, vous pouvez utiliser le symbole astérisque `*` pour faire référence à tous ces objets. +Pour les `nonResourceURLs`, vous pouvez utiliser le symbole astérisque `*` comme suffixe de correspondance glob et pour les `apiGroups` et les `resourceNames` un ensemble vide signifie que tout est autorisé. +Voici un exemple qui autorise l'accès pour effectuer toute action actuelle et future sur toutes les ressources actuelles et futures (remarque, ceci est similaire au rôle `cluster-admin` intégré). ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -310,9 +306,9 @@ rules: ``` {{< caution >}} -Using wildcards in resource and verb entries could result in overly permissive access being granted to sensitive resources. -For instance, if a new resource type is added, or a new subresource is added, or a new custom verb is checked, the wildcard entry automatically grants access, which may be undesirable. -The [principle of least privilege](/docs/concepts/security/rbac-good-practices/#least-privilege) should be employed, using specific resources and verbs to ensure only the permissions required for the workload to function correctly are applied. +L'utilisation d'astérisques dans les entrées de ressources et de verbes peut entraîner l'octroi d'un accès trop permissif à des ressources sensibles. +Par exemple, si un nouveau type de ressource est ajouté, ou si une nouvelle sous-ressource est ajoutée, ou si un nouveau verbe personnalisé est coché, l'utilisation de l'astérisque accorde automatiquement l'accès, ce qui peut être indésirable. +Le [principe du moindre privilège](/docs/concepts/security/rbac-good-practices/#least-privilege) doit être employé, en utilisant des ressources et des verbes spécifiques pour garantir que seules les autorisations nécessaires au bon fonctionnement de la charge de travail sont appliquées. {{< /caution >}} From 23b5c47e643c05177ae5fd754681c17a5e9d52aa Mon Sep 17 00:00:00 2001 From: vincent Date: Tue, 21 Feb 2023 23:39:06 +0000 Subject: [PATCH 04/14] Translate rbac/Aggregated ClusterRoles --- .../docs/reference/access-authn-authz/rbac.md | 71 +++++++++---------- 1 file changed, 35 insertions(+), 36 deletions(-) diff --git a/content/fr/docs/reference/access-authn-authz/rbac.md b/content/fr/docs/reference/access-authn-authz/rbac.md index c7af56ce881..5c74949a86d 100644 --- a/content/fr/docs/reference/access-authn-authz/rbac.md +++ b/content/fr/docs/reference/access-authn-authz/rbac.md @@ -314,20 +314,19 @@ Le [principe du moindre privilège](/docs/concepts/security/rbac-good-practices/ ### Aggregated ClusterRoles -You can _aggregate_ several ClusterRoles into one combined ClusterRole. -A controller, running as part of the cluster control plane, watches for ClusterRole -objects with an `aggregationRule` set. The `aggregationRule` defines a label -{{< glossary_tooltip text="selector" term_id="selector" >}} that the controller -uses to match other ClusterRole objects that should be combined into the `rules` -field of this one. +Vous pouvez _agréger_ plusieurs ClusterRoles en un seul ClusterRole combiné. +Un contrôleur, qui s'exécute dans le cadre du plan de contrôle du cluster, recherche les objets ClusterRole +avec une `aggregationRule` définie. L'`aggregationRule` définit un label +{{< glossary_tooltip text="selector" term_id="selector" >}} que le contrôleur +utilise pour faire correspondre d'autres objets ClusterRole qui devraient être combinés dans le champ de règles de celui-ci. {{< caution >}} -The control plane overwrites any values that you manually specify in the `rules` field of an -aggregate ClusterRole. If you want to change or add rules, do so in the `ClusterRole` objects -that are selected by the `aggregationRule`. +Le plan de contrôle écrase toutes les valeurs que vous spécifiez manuellement dans le champ `rules` d'un ClusterRole agrégé. +Si vous souhaitez modifier ou ajouter des règles, faites-le dans les objets `ClusterRole` +qui sont sélectionnés par l'`aggregationRule`. {{< /caution >}} -Here is an example aggregated ClusterRole: +Voici un exemple de ClusterRole agrégé : ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -341,10 +340,10 @@ aggregationRule: rules: [] # The control plane automatically fills in the rules ``` -If you create a new ClusterRole that matches the label selector of an existing aggregated ClusterRole, -that change triggers adding the new rules into the aggregated ClusterRole. -Here is an example that adds rules to the "monitoring" ClusterRole, by creating another -ClusterRole labeled `rbac.example.com/aggregate-to-monitoring: true`. +Si vous créez un nouvel ClusterRole qui correspond au sélecteur d'étiquette d'une ClusterRole +agrégé existant, ce changement déclenche l'ajout des nouvelles règles dans le ClusterRole agrégé. +Voici un exemple qui ajoute des règles au ClusterRole "monitoring", en créant un autre ClusterRole +étiqueté `rbac.example.com/aggregate-to-monitoring: true`. ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -361,14 +360,14 @@ rules: verbs: ["get", "list", "watch"] ``` -The [default user-facing roles](#default-roles-and-role-bindings) use ClusterRole aggregation. This lets you, -as a cluster administrator, include rules for custom resources, such as those served by +Les [rôles par défaut](#default-roles-and-role-bindings) destinés aux utilisateurs utilisent l'agrégation ClusterRole. Cela vous permet, +en tant qu'administrateur de cluster, d'inclure des règles pour les ressources personnalisées, telles que celles servies par {{< glossary_tooltip term_id="CustomResourceDefinition" text="CustomResourceDefinitions" >}} -or aggregated API servers, to extend the default roles. +ou les serveurs API agrégés, afin d'étendre les rôles par défaut. -For example: the following ClusterRoles let the "admin" and "edit" default roles manage the custom resource -named CronTab, whereas the "view" role can perform only read actions on CronTab resources. -You can assume that CronTab objects are named `"crontabs"` in URLs as seen by the API server. +Par exemple : les ClusterRoles suivants permettent aux rôles par défaut "admin" et "edit" de gérer la ressource personnalisée +nommée CronTab, tandis que le rôle "view" ne peut effectuer que des actions de lecture sur les ressources CronTab. +Vous pouvez supposer que les objets CronTab sont nommés `"crontabs"` dans les URLs telles que vues par le serveur API. ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -399,11 +398,11 @@ rules: #### Role examples -The following examples are excerpts from Role or ClusterRole objects, showing only -the `rules` section. +Les exemples suivants sont des extraits d'objets Role ou ClusterRole, +montrant uniquement la section `rules`. -Allow reading `"pods"` resources in the core -{{< glossary_tooltip text="API Group" term_id="api-group" >}}: +Autoriser la lecture des ressources `"pods"` dans l' +{{< glossary_tooltip text="API Group" term_id="api-group" >}} central : ```yaml rules: @@ -415,8 +414,8 @@ rules: verbs: ["get", "list", "watch"] ``` -Allow reading/writing Deployments (at the HTTP level: objects with `"deployments"` -in the resource part of their URL) in the `"apps"` API groups: +Autoriser la lecture/écriture des Déploiements (au niveau HTTP : objets avec `"deployments"` +dans la partie ressource de leur URL) dans les groupes API `"apps"` : ```yaml rules: @@ -428,8 +427,8 @@ rules: verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] ``` -Allow reading Pods in the core API group, as well as reading or writing Job -resources in the `"batch"` API group: +Autorise la lecture des Pods dans le groupe d'API central, ainsi que de lire ou d'écrire +des ressources Job dans le groupe d'API `"batch"` : ```yaml rules: @@ -447,8 +446,8 @@ rules: verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] ``` -Allow reading a ConfigMap named "my-config" (must be bound with a -RoleBinding to limit to a single ConfigMap in a single namespace): +Autoriser la lecture d'un ConfigMap nommé "my-config" +(doit être lié avec un RoleBinding pour limiter à un seul ConfigMap dans un seul namespace). ```yaml rules: @@ -461,9 +460,9 @@ rules: verbs: ["get"] ``` -Allow reading the resource `"nodes"` in the core group (because a -Node is cluster-scoped, this must be in a ClusterRole bound with a -ClusterRoleBinding to be effective): +Autoriser la lecture des ressources `"nodes"`dans le groupe central (parce +qu'un Node est à l'échelle-du-cluster, il doit être dans un ClusterRole +lié à un ClusterRoleBinding pour être effectif) : ```yaml rules: @@ -475,9 +474,9 @@ rules: verbs: ["get", "list", "watch"] ``` -Allow GET and POST requests to the non-resource endpoint `/healthz` and -all subpaths (must be in a ClusterRole bound with a ClusterRoleBinding -to be effective): +Autorise les requêtes GET et POST vers l'endpoint non ressource `/healthz` et +tous les subpaths (doit être dans un ClusterRole lié à un ClusterRoleBinding +pour être effectif) : ```yaml rules: From e06607c1c182597d65b4cec07a688e6cfb51ce65 Mon Sep 17 00:00:00 2001 From: vincent Date: Wed, 22 Feb 2023 23:29:45 +0000 Subject: [PATCH 05/14] Translate rbac/Referring to subject --- .../fr/docs/reference/access-authn-authz/rbac.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/content/fr/docs/reference/access-authn-authz/rbac.md b/content/fr/docs/reference/access-authn-authz/rbac.md index 5c74949a86d..91301b2e32c 100644 --- a/content/fr/docs/reference/access-authn-authz/rbac.md +++ b/content/fr/docs/reference/access-authn-authz/rbac.md @@ -486,15 +486,15 @@ rules: ### Referring to subjects -A RoleBinding or ClusterRoleBinding binds a role to subjects. -Subjects can be groups, users or +Un RoleBinding ou ClusterRoleBinding lie un rôle à des sujets. +Les sujets peuvent être des groupes, des utilisateurs ou des {{< glossary_tooltip text="ServiceAccounts" term_id="service-account" >}}. -Kubernetes represents usernames as strings. -These can be: plain names, such as "alice"; email-style names, like "bob@example.com"; -or numeric user IDs represented as a string. It is up to you as a cluster administrator -to configure the [authentication modules](/docs/reference/access-authn-authz/authentication/) -so that authentication produces usernames in the format you want. +Kubernetes représente les noms d'utilisateurs sous forme de chaînes de caractères. +Il peut s'agir: de noms simples, tels que "alice"; de noms de style e-mail, tels que "bob@example.com"; +ou des IDs d'utilisateur numériques représentés sous forme de chaîne de caractères. Il vous appartient, en tant qu'administrateur de cluster, +de configurer les [modules d'authentification](/docs/reference/access-authn-authz/authentication/) +afin que l'authentification produise des noms d'utilisateur dans le format que vous souhaitez. {{< caution >}} The prefix `system:` is reserved for Kubernetes system use, so you should ensure From b2352e3dd526b6dcbe077b625e6df7e526d32583 Mon Sep 17 00:00:00 2001 From: vincent Date: Thu, 23 Feb 2023 22:37:02 +0000 Subject: [PATCH 06/14] Translate rbac/Referring to subject --- .../docs/reference/access-authn-authz/rbac.md | 50 +++++++++---------- 1 file changed, 25 insertions(+), 25 deletions(-) diff --git a/content/fr/docs/reference/access-authn-authz/rbac.md b/content/fr/docs/reference/access-authn-authz/rbac.md index 91301b2e32c..430cf10bfca 100644 --- a/content/fr/docs/reference/access-authn-authz/rbac.md +++ b/content/fr/docs/reference/access-authn-authz/rbac.md @@ -312,7 +312,7 @@ Le [principe du moindre privilège](/docs/concepts/security/rbac-good-practices/ {{< /caution >}} -### Aggregated ClusterRoles +### ClusterRoles agrégés Vous pouvez _agréger_ plusieurs ClusterRoles en un seul ClusterRole combiné. Un contrôleur, qui s'exécute dans le cadre du plan de contrôle du cluster, recherche les objets ClusterRole @@ -484,7 +484,7 @@ rules: verbs: ["get", "post"] ``` -### Referring to subjects +### Référence à des subjects Un RoleBinding ou ClusterRoleBinding lie un rôle à des sujets. Les sujets peuvent être des groupes, des utilisateurs ou des @@ -497,31 +497,31 @@ de configurer les [modules d'authentification](/docs/reference/access-authn-auth afin que l'authentification produise des noms d'utilisateur dans le format que vous souhaitez. {{< caution >}} -The prefix `system:` is reserved for Kubernetes system use, so you should ensure -that you don't have users or groups with names that start with `system:` by -accident. -Other than this special prefix, the RBAC authorization system does not require any format -for usernames. +Le préfixe `system:` est réservé à l'utilisation du système Kubernetes, vous devez donc vous assurer +que vous n'avez pas d'utilisateurs ou de groupes dont le nom commence par `system:` +par accident. +En dehors de ce préfixe spécial, le système d'autorisation RBAC ne requiert aucun format pour les +noms d'utilisateurs. {{< /caution >}} -In Kubernetes, Authenticator modules provide group information. -Groups, like users, are represented as strings, and that string has no format requirements, -other than that the prefix `system:` is reserved. +Dans Kubernetes, les modules Authenticator fournissent des informations sur les groupes. +Les groupes, comme les utilisateurs, sont représentés sous forme de chaînes de caractères et cette chaîne n'a aucune exigence de format, +si ce n'est que le préfixe `system:` est réservé. -[ServiceAccounts](/docs/tasks/configure-pod-container/configure-service-account/) have names prefixed -with `system:serviceaccount:`, and belong to groups that have names prefixed with `system:serviceaccounts:`. +Les [ServiceAccounts](/docs/tasks/configure-pod-container/configure-service-account/) ont des noms préfixés par +`system:serviceaccount:`, et appartiennent à des groupes qui ont des noms préfixés par `system:serviceaccounts:`. {{< note >}} -- `system:serviceaccount:` (singular) is the prefix for service account usernames. -- `system:serviceaccounts:` (plural) is the prefix for service account groups. +- `system:serviceaccount:` (singulier) est le préfixe pour les noms d'utilisateur des comptes de service. +- `system:serviceaccounts:` (pluriel) est le préfixe pour les groupes de comptes de service. {{< /note >}} -#### RoleBinding examples {#role-binding-examples} +#### Exemples de RoleBinding {#role-binding-examples} -The following examples are `RoleBinding` excerpts that only -show the `subjects` section. +Les exemples suivants sont des extraits de `RoleBinding` +qui ne montrent que la section des `subjects`. -For a user named `alice@example.com`: +Pour un utilisateur nommé `alice@example.com` : ```yaml subjects: @@ -530,7 +530,7 @@ subjects: apiGroup: rbac.authorization.k8s.io ``` -For a group named `frontend-admins`: +Pour un groupe nommé `frontend-admins`: ```yaml subjects: @@ -539,7 +539,7 @@ subjects: apiGroup: rbac.authorization.k8s.io ``` -For the default service account in the "kube-system" namespace: +Pour le compte de service par défaut dans le namespace "kube-system" : ```yaml subjects: @@ -548,7 +548,7 @@ subjects: namespace: kube-system ``` -For all service accounts in the "qa" namespace: +Pour tous les comptes de service dans le namespace "qa" : ```yaml subjects: @@ -557,7 +557,7 @@ subjects: apiGroup: rbac.authorization.k8s.io ``` -For all service accounts in any namespace: +Pour tous les comptes de service dans n'importe quel namespace : ```yaml subjects: @@ -566,7 +566,7 @@ subjects: apiGroup: rbac.authorization.k8s.io ``` -For all authenticated users: +Pour tous les utilisateurs authentifiés : ```yaml subjects: @@ -575,7 +575,7 @@ subjects: apiGroup: rbac.authorization.k8s.io ``` -For all unauthenticated users: +Pour tous les utilisateurs non authentifiés : ```yaml subjects: @@ -584,7 +584,7 @@ subjects: apiGroup: rbac.authorization.k8s.io ``` -For all users: +Pour tous les utilisateurs : ```yaml subjects: From 97458ae0fde3a44a76324a53f3634d9dae71b325 Mon Sep 17 00:00:00 2001 From: vincent Date: Fri, 24 Feb 2023 04:16:04 +0000 Subject: [PATCH 07/14] Translate rbac/Auto-reconciliation --- .../docs/reference/access-authn-authz/rbac.md | 32 ++++++++++--------- 1 file changed, 17 insertions(+), 15 deletions(-) diff --git a/content/fr/docs/reference/access-authn-authz/rbac.md b/content/fr/docs/reference/access-authn-authz/rbac.md index 430cf10bfca..e1709ab2ac9 100644 --- a/content/fr/docs/reference/access-authn-authz/rbac.md +++ b/content/fr/docs/reference/access-authn-authz/rbac.md @@ -596,31 +596,33 @@ subjects: apiGroup: rbac.authorization.k8s.io ``` -## Default roles and role bindings +## Rôles par défaut et liaisons de rôles -API servers create a set of default ClusterRole and ClusterRoleBinding objects. -Many of these are `system:` prefixed, which indicates that the resource is directly -managed by the cluster control plane. -All of the default ClusterRoles and ClusterRoleBindings are labeled with `kubernetes.io/bootstrapping=rbac-defaults`. +Les serveurs API créent un ensemble d'objets ClusterRole et ClusterRoleBinding par défaut. +Beaucoup d'entre eux sont préfixés `system:`, ce qui indique que la ressource est directement +gérée par le plan de contrôle du cluster. +Tous les ClusterRoles et ClusterRoleBindings par défaut sont étiquetés avec `kubernetes.io/bootstrapping=rbac-defaults`. {{< caution >}} -Take care when modifying ClusterRoles and ClusterRoleBindings with names -that have a `system:` prefix. -Modifications to these resources can result in non-functional clusters. +Faites attention lorsque vous modifiez les ClusterRoles et les ClusterRoleBindings +dont les noms ont un préfixe `system:`. +Les modifications apportées à ces ressources peuvent entraîner des clusters non fonctionnels. {{< /caution >}} ### Auto-reconciliation -At each start-up, the API server updates default cluster roles with any missing permissions, -and updates default cluster role bindings with any missing subjects. -This allows the cluster to repair accidental modifications, and helps to keep roles and role bindings -up-to-date as permissions and subjects change in new Kubernetes releases. +À chaque démarrage, le serveur API met à jour les rôles de cluster par défaut avec toutes les permissions manquantes, +et met à jour les liaisons de rôles de cluster par défaut avec tous les sujets manquants. +Cela permet au cluster de réparer les modifications accidentelles, et aide à maintenir les rôles et les liaisons de rôles +à jour lorsque les autorisations et les sujets changent dans les nouvelles versions de Kubernetes. -To opt out of this reconciliation, set the `rbac.authorization.kubernetes.io/autoupdate` -annotation on a default cluster role or rolebinding to `false`. Be aware that missing default permissions and subjects can result in non-functional clusters. +Pour ne pas participer à cette reconciliation, définissez l'annotation `rbac.authorization.kubernetes.io/autoupdate` +sur un rôle ou un rolebinding de cluster par défaut sur `false`. +Sachez que les autorisations et les sujets par défaut manquants peuvent entraîner des clusters non fonctionnels. + +L'auto-réconciliation est activée par défaut si l'autorisateur RBAC est actif. -Auto-reconciliation is enabled by default if the RBAC authorizer is active. ### API discovery roles {#discovery-roles} From 19e89507d06ef4d0a8b0910a23c0ae4671e9165c Mon Sep 17 00:00:00 2001 From: vincent Date: Tue, 28 Feb 2023 23:45:25 +0000 Subject: [PATCH 08/14] Translate rbac/API discovery roles --- .../docs/reference/access-authn-authz/rbac.md | 25 ++++++++++--------- 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/content/fr/docs/reference/access-authn-authz/rbac.md b/content/fr/docs/reference/access-authn-authz/rbac.md index e1709ab2ac9..a623282c81d 100644 --- a/content/fr/docs/reference/access-authn-authz/rbac.md +++ b/content/fr/docs/reference/access-authn-authz/rbac.md @@ -624,29 +624,30 @@ Sachez que les autorisations et les sujets par défaut manquants peuvent entraî L'auto-réconciliation est activée par défaut si l'autorisateur RBAC est actif. -### API discovery roles {#discovery-roles} +### Rôles de détection de l'API {#discovery-roles} -Default role bindings authorize unauthenticated and authenticated users to read API information that is deemed safe to be publicly accessible (including CustomResourceDefinitions). To disable anonymous unauthenticated access, add `--anonymous-auth=false` to the API server configuration. +Les liaisons de rôles par défaut autorisent les utilisateurs authentifiés et non authentifiés à lire les informations de l'API qui sont jugées sûres pour être accessibles au public (y compris les CustomResourceDefinitions). Pour désactiver l'accès anonyme non authentifié, ajoutez `--anonymous-auth=false` à la configuration du serveur d'API. + +Pour afficher la configuration de ces rôles via `kubectl`, exécutez : -To view the configuration of these roles via `kubectl` run: ```shell kubectl get clusterroles system:discovery -o yaml ``` {{< note >}} -If you edit that ClusterRole, your changes will be overwritten on API server restart -via [auto-reconciliation](#auto-reconciliation). To avoid that overwriting, -either do not manually edit the role, or disable auto-reconciliation. +Si vous modifiez ce ClusterRole, vos modifications seront écrasées au redémarrage du serveur API +via l'[auto-reconciliation](#auto-reconciliation). Pour éviter cet écrasement, +ne modifiez pas manuellement le rôle ou désactivez l'auto-reconciliation. {{< /note >}} - + - - + + @@ -654,17 +655,17 @@ either do not manually edit the role, or disable auto-reconciliation. - + - + - +
Kubernetes RBAC API discovery rolesRôles de détection de l'API RBAC de Kubernetes
Default ClusterRoleDefault ClusterRoleBindingClusterRole par défautClusterRoleBinding par défaut Description
system:basic-user system:authenticated groupAllows a user read-only access to basic information about themselves. Prior to v1.14, this role was also bound to system:unauthenticated by default.Permet à un utilisateur d'accéder en lecture seule aux informations de base le concernant. Avant la v1.14, ce rôle était également lié à system:unauthenticated par défaut.
system:discovery system:authenticated groupAllows read-only access to API discovery endpoints needed to discover and negotiate an API level. Prior to v1.14, this role was also bound to system:unauthenticated by default.Permet un accès en lecture seule aux points de terminaison de découverte d'API nécessaires pour découvrir et négocier un niveau d'API. Avant la v1.14, ce rôle était également lié à l'option system:unauthenticated par défaut.
system:public-info-viewer system:authenticated and system:unauthenticated groupsAllows read-only access to non-sensitive information about the cluster. Introduced in Kubernetes v1.14.Permet un accès en lecture seule à des informations non sensibles sur le cluster. Introduit dans Kubernetes v1.14.
From 8bb238d22d9010b16eb186c46b89445cb0f5e955 Mon Sep 17 00:00:00 2001 From: vincent Date: Thu, 2 Mar 2023 23:17:07 +0000 Subject: [PATCH 09/14] Translate rbac add access folder --- .../docs/reference/access-authn-authz/rbac.md | 69 ++++++++++--------- .../clusterrole-approve.yaml | 28 ++++++++ .../clusterrole-create.yaml | 14 ++++ .../clusterrole-sign.yaml | 27 ++++++++ .../examples/access/endpoints-aggregated.yaml | 20 ++++++ 5 files changed, 125 insertions(+), 33 deletions(-) create mode 100644 content/fr/examples/access/certificate-signing-request/clusterrole-approve.yaml create mode 100644 content/fr/examples/access/certificate-signing-request/clusterrole-create.yaml create mode 100644 content/fr/examples/access/certificate-signing-request/clusterrole-sign.yaml create mode 100644 content/fr/examples/access/endpoints-aggregated.yaml diff --git a/content/fr/docs/reference/access-authn-authz/rbac.md b/content/fr/docs/reference/access-authn-authz/rbac.md index a623282c81d..42815e64cf7 100644 --- a/content/fr/docs/reference/access-authn-authz/rbac.md +++ b/content/fr/docs/reference/access-authn-authz/rbac.md @@ -670,16 +670,16 @@ ne modifiez pas manuellement le rôle ou désactivez l'auto-reconciliation. -### User-facing roles +### Rôle des utilisateurs -Some of the default ClusterRoles are not `system:` prefixed. These are intended to be user-facing roles. -They include super-user roles (`cluster-admin`), roles intended to be granted cluster-wide -using ClusterRoleBindings, and roles intended to be granted within particular -namespaces using RoleBindings (`admin`, `edit`, `view`). +Certains des ClusterRoles par défaut ne sont pas précédés du préfixe `system:`. Il s'agit de rôles destinés à l'utilisateur. +Ils incluent les rôles de super-utilisateur (`cluster-admin`), les rôles destinés à être accordés à l'échelle du cluster +à l'aide de ClusterRoleBindings, et les rôles destinés à être accordés dans +des namespaces particuliers à l'aide de RoleBindings (`admin`, `edit`, `view`). -User-facing ClusterRoles use [ClusterRole aggregation](#aggregated-clusterroles) to allow admins to include -rules for custom resources on these ClusterRoles. To add rules to the `admin`, `edit`, or `view` roles, create -a ClusterRole with one or more of the following labels: +Les ClusterRoles des utilisateurs utilisent l'[agrégation de ClusterRole](#aggregated-clusterroles) pour permettre aux administrateurs d'inclure +des règles pour les ressources personnalisées sur ces ClusterRoles. Pour ajouter des règles aux rôles `admin`, `edit`, ou `view`, créez +une ClusterRole avec un ou plusieurs des labels suivants : ```yaml metadata: @@ -693,48 +693,51 @@ metadata: -Default ClusterRole -Default ClusterRoleBinding +ClusterRole par défaut +ClusterRoleBinding par défaut Description cluster-admin -system:masters group -Allows super-user access to perform any action on any resource. -When used in a ClusterRoleBinding, it gives full control over every resource in the cluster and in all namespaces. -When used in a RoleBinding, it gives full control over every resource in the role binding's namespace, including the namespace itself. +system:masters groupe +Permet au super-utilisateur d'effectuer n'importe quelle action sur n'importe quelle ressource. +Lorsqu'il est utilisé dans un ClusterRoleBinding, il donne un contrôle total sur chaque ressource dans le cluster et dans tous les namespaces. +Lorsqu'il est utilisé dans un RoleBinding, il donne un contrôle total sur chaque ressource dans le namespace du role binding, y compris le namespace lui-même. admin -None -Allows admin access, intended to be granted within a namespace using a RoleBinding. +Aucun +Permet l'accès administrateur, destiné à être accordé au sein d'un espace de nom en utilisant un RoleBinding. -If used in a RoleBinding, allows read/write access to most resources in a namespace, -including the ability to create roles and role bindings within the namespace. -This role does not allow write access to resource quota or to the namespace itself. -This role also does not allow write access to EndpointSlices (or Endpoints) in clusters created -using Kubernetes v1.22+. More information is available in the -["Write Access for EndpointSlices and Endpoints" section](#write-access-for-endpoints). +S'il est utilisé dans un RoleBinding, il permet un accès en lecture/écriture à la plupart des ressources d'un namespace, +y compris la possibilité de créer des rôles et des liaisons de rôles dans le namespace. +Ce rôle ne permet pas l'accès en écriture au quota de ressources ou au namespace lui-même. +Ce rôle ne permet pas non plus l'accès en écriture aux EndpointSlices (ou Endpoints) dans les clusters créés +à l'aide de Kubernetes v1.22+. Plus d'informations sont disponibles dans la +[section "Accès en écriture pour les EndpointSlices et les Endpoints"](#write-access-for-endpoints). edit -None -Allows read/write access to most objects in a namespace. +Aucun +Permet l'accès en lecture/écriture à la plupart des objets d'un namespace. -This role does not allow viewing or modifying roles or role bindings. -However, this role allows accessing Secrets and running Pods as any ServiceAccount in -the namespace, so it can be used to gain the API access levels of any ServiceAccount in -the namespace. This role also does not allow write access to EndpointSlices (or Endpoints) in -clusters created using Kubernetes v1.22+. More information is available in the -["Write Access for EndpointSlices and Endpoints" section](#write-access-for-endpoints). +Ce rôle ne permet pas de visualiser ou de modifier les rôles ou les liaisons de rôles. +Cependant, ce rôle permet d'accéder aux Secrets et d'exécuter des Pods comme n'importe quel ServiceAccount +du namespace, il peut donc être utilisé pour obtenir les niveaux d'accès API de n'importe quel ServiceAccount +du namespace. Ce rôle ne permet pas non plus d'accéder en écriture aux EndpointSlices (ou Endpoints) dans +les clusters créés à l'aide de Kubernetes v1.22+. Plus d'informations sont disponibles dans la +[section "Write Access for EndpointSlices and Endpoints"](#write-access-for-endpoints). view -None -Allows read-only access to see most objects in a namespace. -It does not allow viewing roles or role bindings. +Aucun +Permet un accès en lecture seule pour voir la plupart des objets d'un namespace. +Il ne permet pas de visualiser les rôles ou les liens entre les rôles. +Ce rôle ne permet pas de visualiser les Secrets, car la lecture du contenu +des Secrets permet d'accéder aux informations d'identification du ServiceAccount dans le namespace, +ce qui permettrait d'accéder à l'API en tant que tout ServiceAccount dans l'espace de noms (une forme d'escalade des privilèges). This role does not allow viewing Secrets, since reading the contents of Secrets enables access to ServiceAccount credentials diff --git a/content/fr/examples/access/certificate-signing-request/clusterrole-approve.yaml b/content/fr/examples/access/certificate-signing-request/clusterrole-approve.yaml new file mode 100644 index 00000000000..e5bcfdc44e2 --- /dev/null +++ b/content/fr/examples/access/certificate-signing-request/clusterrole-approve.yaml @@ -0,0 +1,28 @@ +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: csr-approver +rules: +- apiGroups: + - certificates.k8s.io + resources: + - certificatesigningrequests + verbs: + - get + - list + - watch +- apiGroups: + - certificates.k8s.io + resources: + - certificatesigningrequests/approval + verbs: + - update +- apiGroups: + - certificates.k8s.io + resources: + - signers + resourceNames: + - example.com/my-signer-name # example.com/* can be used to authorize for all signers in the 'example.com' domain + verbs: + - approve + diff --git a/content/fr/examples/access/certificate-signing-request/clusterrole-create.yaml b/content/fr/examples/access/certificate-signing-request/clusterrole-create.yaml new file mode 100644 index 00000000000..def1b879d8e --- /dev/null +++ b/content/fr/examples/access/certificate-signing-request/clusterrole-create.yaml @@ -0,0 +1,14 @@ +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: csr-creator +rules: +- apiGroups: + - certificates.k8s.io + resources: + - certificatesigningrequests + verbs: + - create + - get + - list + - watch diff --git a/content/fr/examples/access/certificate-signing-request/clusterrole-sign.yaml b/content/fr/examples/access/certificate-signing-request/clusterrole-sign.yaml new file mode 100644 index 00000000000..6d1a2f7882c --- /dev/null +++ b/content/fr/examples/access/certificate-signing-request/clusterrole-sign.yaml @@ -0,0 +1,27 @@ +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: csr-signer +rules: +- apiGroups: + - certificates.k8s.io + resources: + - certificatesigningrequests + verbs: + - get + - list + - watch +- apiGroups: + - certificates.k8s.io + resources: + - certificatesigningrequests/status + verbs: + - update +- apiGroups: + - certificates.k8s.io + resources: + - signers + resourceNames: + - example.com/my-signer-name # example.com/* can be used to authorize for all signers in the 'example.com' domain + verbs: + - sign diff --git a/content/fr/examples/access/endpoints-aggregated.yaml b/content/fr/examples/access/endpoints-aggregated.yaml new file mode 100644 index 00000000000..d238820056a --- /dev/null +++ b/content/fr/examples/access/endpoints-aggregated.yaml @@ -0,0 +1,20 @@ +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + annotations: + kubernetes.io/description: |- + Add endpoints write permissions to the edit and admin roles. This was + removed by default in 1.22 because of CVE-2021-25740. See + https://issue.k8s.io/103675. This can allow writers to direct LoadBalancer + or Ingress implementations to expose backend IPs that would not otherwise + be accessible, and can circumvent network policies or security controls + intended to prevent/isolate access to those backends. + EndpointSlices were never included in the edit or admin roles, so there + is nothing to restore for the EndpointSlice API. + labels: + rbac.authorization.k8s.io/aggregate-to-edit: "true" + name: custom:aggregate-to-edit:endpoints # you can change this if you wish +rules: + - apiGroups: [""] + resources: ["endpoints"] + verbs: ["create", "delete", "deletecollection", "patch", "update"] From 46f3bb0aea5217fb143449f3e6e5c4cde5d2db87 Mon Sep 17 00:00:00 2001 From: vincent Date: Fri, 3 Mar 2023 05:16:39 +0000 Subject: [PATCH 10/14] Translation of rbac/Core role component --- .../docs/reference/access-authn-authz/rbac.md | 36 +++++++++---------- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/content/fr/docs/reference/access-authn-authz/rbac.md b/content/fr/docs/reference/access-authn-authz/rbac.md index 42815e64cf7..5b69552f182 100644 --- a/content/fr/docs/reference/access-authn-authz/rbac.md +++ b/content/fr/docs/reference/access-authn-authz/rbac.md @@ -739,56 +739,56 @@ Ce rôle ne permet pas de visualiser les Secrets, car la lecture du contenu des Secrets permet d'accéder aux informations d'identification du ServiceAccount dans le namespace, ce qui permettrait d'accéder à l'API en tant que tout ServiceAccount dans l'espace de noms (une forme d'escalade des privilèges). -This role does not allow viewing Secrets, since reading -the contents of Secrets enables access to ServiceAccount credentials -in the namespace, which would allow API access as any ServiceAccount -in the namespace (a form of privilege escalation). +Ce rôle ne permet pas de consulter les secrets, car la lecture +du contenu des secrets permet d'accéder aux informations d'identification du ServiceAccount dans le namespace, +ce qui permettrait d'accéder à l'API en tant que n'importe quel ServiceAccount +dans le namespace (une forme d'escalade des privilèges). -### Core component roles +### Rôles des composants de base - - + + - - + + - + - - + + - - + - +
Default ClusterRoleDefault ClusterRoleBindingClusterRole par défautClusterRoleBinding par défaut Description
system:kube-schedulersystem:kube-scheduler userAllows access to the resources required by the {{< glossary_tooltip term_id="kube-scheduler" text="scheduler" >}} component.utilisateur system:kube-schedulerPermet l'accès aux ressources requises par le composant {{< glossary_tooltip term_id="kube-scheduler" text="scheduler" >}}.
system:volume-scheduler system:kube-scheduler userAllows access to the volume resources required by the kube-scheduler component.Permet l'accès aux ressources de volume requises par le composant kube-scheduler.
system:kube-controller-managersystem:kube-controller-manager userAllows access to the resources required by the {{< glossary_tooltip term_id="kube-controller-manager" text="controller manager" >}} component. -The permissions required by individual controllers are detailed in the controller roles.utilisateur system:kube-controller-managerPermet l'accès aux ressources requises par le composant {{< glossary_tooltip term_id="kube-controller-manager" text="gestionnaire de contrôleur" >}}. +Les autorisations requises par les contrôleurs individuels sont détaillées dans les rôles des contrôleurs.
system:nodeNoneAllows access to resources required by the kubelet, including read access to all secrets, and write access to all pod status objects. +AucunPermet l'accès aux ressources requises par le kubelet, y compris l'accès en lecture à tous les secrets, et l'accès en écriture à tous les objets d'état des pods. -You should use the Node authorizer and NodeRestriction admission plugin instead of the system:node role, and allow granting API access to kubelets based on the Pods scheduled to run on them. +Vous devriez utiliser le Node authorizer et le plugin d'admission NodeRestriction au lieu du rôle system:node, et autoriser l'octroi d'un accès API aux kubelets en fonction des Pods programmés pour s'exécuter sur eux. -The system:node role only exists for compatibility with Kubernetes clusters upgraded from versions prior to v1.8. +Le rôle system:node n'existe que pour la compatibilité avec les clusters Kubernetes mis à niveau à partir de versions antérieures à la v1.8.
system:node-proxier system:kube-proxy userAllows access to the resources required by the {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}} component.Permet l'accès aux ressources requises par le composant {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}.
From e99828abaa56df9c20d274d0feeca5da3626ce78 Mon Sep 17 00:00:00 2001 From: vincent Date: Mon, 20 Mar 2023 04:52:59 +0000 Subject: [PATCH 11/14] Translation of rbac/Other component role --- .../docs/reference/access-authn-authz/rbac.md | 38 +++++++++---------- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/content/fr/docs/reference/access-authn-authz/rbac.md b/content/fr/docs/reference/access-authn-authz/rbac.md index 5b69552f182..ab28803fd58 100644 --- a/content/fr/docs/reference/access-authn-authz/rbac.md +++ b/content/fr/docs/reference/access-authn-authz/rbac.md @@ -793,7 +793,7 @@ Le rôle system:node n'existe que pour la compatibilité avec les clust -### Other component roles +### Autres rôles des composants @@ -807,50 +807,50 @@ Le rôle system:node n'existe que pour la compatibilité avec les clust - - + + - - + + - + - - + + - - + + - - + - - + + - - + + - - + +
system:auth-delegatorNoneAllows delegated authentication and authorization checks. -This is commonly used by add-on API servers for unified authentication and authorization.AucunPermet de déléguer les contrôles d'authentification et d'autorisation. +Il est couramment utilisé par les serveurs API complémentaires pour l'authentification et l'autorisation unifiées.
system:heapsterNoneRole for the Heapster component (deprecated).AucunRôle du composant Heapster Heapster (déprécié).
system:kube-aggregatorNoneAucun Role for the kube-aggregator component.
system:kube-dnskube-dns service account in the kube-system namespaceRole for the kube-dns component.kube-dns compte de service kube-dns dans le namespace du kube-systemRôle du composant kube-dns .
system:kubelet-api-adminNoneAllows full access to the kubelet API.AucunPermet un accès complet à l'API kubelet.
system:node-bootstrapperNoneAllows access to the resources required to perform +AucunPermet d'accéder aux ressources nécessaires pour effectuer un kubelet TLS bootstrapping.
system:node-problem-detectorNoneRole for the node-problem-detector component.AucunRôle du component node-problem-detector .
system:persistent-volume-provisionerNoneAllows access to the resources required by most dynamic volume provisioners.AucunPermet d'accéder aux ressources requises par la plupart des fournisseurs de volumes dynamiques .
system:monitoringsystem:monitoring groupAllows read access to control-plane monitoring endpoints (i.e. {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} liveness and readiness endpoints (/healthz, /livez, /readyz), the individual health-check endpoints (/healthz/*, /livez/*, /readyz/*), and /metrics). Note that individual health check endpoints and the metric endpoint may expose sensitive information.groupe system:monitoringAutorise l'accès en lecture aux endpoints de monitoring du control-plane (c'est-à-dire les endpoints {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} liveness and readiness (/healthz, /livez, /readyz), les endpoints de contrôle de l'état individuel (/healthz/*, /livez/*, /readyz/*), et /metrics). Il convient de noter que les endpoints des contrôles de l'état individuel et les endpoints des mesures peuvent exposer des informations sensibles.
From 381ae558145d9d68a0f5da60e51e243e1147f305 Mon Sep 17 00:00:00 2001 From: vincent Date: Mon, 20 Mar 2023 04:59:06 +0000 Subject: [PATCH 12/14] Translation of rbac/Role of buid in controller --- content/fr/docs/reference/access-authn-authz/rbac.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/fr/docs/reference/access-authn-authz/rbac.md b/content/fr/docs/reference/access-authn-authz/rbac.md index ab28803fd58..aa09c0d33eb 100644 --- a/content/fr/docs/reference/access-authn-authz/rbac.md +++ b/content/fr/docs/reference/access-authn-authz/rbac.md @@ -855,7 +855,7 @@ Il est couramment utilisé par les serveurs API complémentaires pour l'authenti -### Roles for built-in controllers {#controller-roles} +### Rôles des contrôleurs intégrés {#controller-roles} The Kubernetes {{< glossary_tooltip term_id="kube-controller-manager" text="controller manager" >}} runs {{< glossary_tooltip term_id="controller" text="controllers" >}} that are built in to the Kubernetes From 27d036ba7f84509bd0757fe0578b2c759b45e4f5 Mon Sep 17 00:00:00 2001 From: vincent Date: Tue, 28 Mar 2023 16:57:46 +0000 Subject: [PATCH 13/14] Translation of rbac/Upgrading from ABAC --- .../docs/reference/access-authn-authz/rbac.md | 309 +++++++++--------- 1 file changed, 151 insertions(+), 158 deletions(-) diff --git a/content/fr/docs/reference/access-authn-authz/rbac.md b/content/fr/docs/reference/access-authn-authz/rbac.md index aa09c0d33eb..a6a9f10fef2 100644 --- a/content/fr/docs/reference/access-authn-authz/rbac.md +++ b/content/fr/docs/reference/access-authn-authz/rbac.md @@ -54,14 +54,9 @@ pour comprendre comment ces restrictions peuvent vous empêcher d'effectuer cert Un _Role_ ou _ClusterRole_ RBAC contient des règles qui représentent un ensemble de permissions. Les permissions sont purement additives (il n'y a pas de "deny" règles). -A Role always sets permissions within a particular {{< glossary_tooltip text="namespace" term_id="namespace" >}}; -when you create a Role, you have to specify the namespace it belongs in. Un rôle définit toujours les autorisations dans un {{< glossary_tooltip text="namespace" term_id="namespace" >}} particulier; lorsque vous créez un Role, vous devez spécifier le namespace auquel il appartient. -ClusterRole, by contrast, is a non-namespaced resource. The resources have different names (Role -and ClusterRole) because a Kubernetes object always has to be either namespaced or not namespaced; -it can't be both. ClusterRole, en revanche, est une ressource sans namespace. Les ressources portent des noms différents (Role et ClusterRole) parce qu'un objet Kubernetes doit toujours être soit avec un namespace ou soit sans namespace; Il ne peut pas être les deux. @@ -857,15 +852,14 @@ Il est couramment utilisé par les serveurs API complémentaires pour l'authenti ### Rôles des contrôleurs intégrés {#controller-roles} -The Kubernetes {{< glossary_tooltip term_id="kube-controller-manager" text="controller manager" >}} runs -{{< glossary_tooltip term_id="controller" text="controllers" >}} that are built in to the Kubernetes -control plane. -When invoked with `--use-service-account-credentials`, kube-controller-manager starts each controller -using a separate service account. -Corresponding roles exist for each built-in controller, prefixed with `system:controller:`. -If the controller manager is not started with `--use-service-account-credentials`, it runs all control loops -using its own credential, which must be granted all the relevant roles. -These roles include: +Le {{< glossary_tooltip term_id="kube-controller-manager" text="gestionnaire de contrôleurs" >}} Kubernetes exécute +les {{< glossary_tooltip term_id="controller" text="contrôleurs" >}} qui sont intégrés au plan de contrôle Kubernetes. +Lorsqu'il est invoqué `--use-service-account-credentials`, kube-controller-manager démarre chaque contrôleur +en utilisant un compte de service distinct. +Des rôles correspondants existent pour chaque contrôleur intégré, préfixés par `system:controller:`. +Si le gestionnaire de contrôleur n'est pas démarré avec `--use-service-account-credentials`, il exécute toutes les boucles de contrôle +en utilisant ses propres informations d'identification, qui doivent se voir attribuer tous les rôles pertinents. +Ces rôles sont les suivants : * `system:controller:attachdetach-controller` * `system:controller:certificate-controller` @@ -895,40 +889,40 @@ These roles include: * `system:controller:statefulset-controller` * `system:controller:ttl-controller` -## Privilege escalation prevention and bootstrapping +## Prévention de l'escalade des privilèges et bootstrapping -The RBAC API prevents users from escalating privileges by editing roles or role bindings. -Because this is enforced at the API level, it applies even when the RBAC authorizer is not in use. +L'API RBAC empêche les utilisateurs d'escalader les privilèges en modifiant les rôles ou les liaisons de rôles. +Cette interdiction étant appliquée au niveau de l'API, elle s'applique même lorsque l'autorisateur RBAC n'est pas utilisé. -### Restrictions on role creation or update +### Restrictions à la création ou à la mise à jour des rôles -You can only create/update a role if at least one of the following things is true: +Vous ne pouvez créer/mettre à jour un rôle que si au moins l'une des choses suivantes est vraie : -1. You already have all the permissions contained in the role, at the same scope as the object being modified -(cluster-wide for a ClusterRole, within the same namespace or cluster-wide for a Role). -2. You are granted explicit permission to perform the `escalate` verb on the `roles` or `clusterroles` resource in the `rbac.authorization.k8s.io` API group. +1. Vous disposez déjà de toutes les autorisations contenues dans le rôle, à la même échelle que l'objet en cours de modification +(à l'échelle du cluster pour un ClusterRole, dans le même namespace ou à l'échelle du cluster pour un Role). +2. Vous avez l'autorisation explicite d'exécuter le verbe `escalader` sur la ressource `roles` ou `clusterroles` dans le groupe API `rbac.authorization.k8s.io`. -For example, if `user-1` does not have the ability to list Secrets cluster-wide, they cannot create a ClusterRole -containing that permission. To allow a user to create/update roles: +Par exemple, si l'`user-1` n'a pas la possibilité de lister les Secrets à l'échelle du cluster, il ne peut pas créer un ClusterRole +contenant cette permission. Pour permettre à un utilisateur de créer/mettre à jour des rôles : -1. Grant them a role that allows them to create/update Role or ClusterRole objects, as desired. -2. Grant them permission to include specific permissions in the roles they create/update: - * implicitly, by giving them those permissions (if they attempt to create or modify a Role or ClusterRole with permissions they themselves have not been granted, the API request will be forbidden) - * or explicitly allow specifying any permission in a `Role` or `ClusterRole` by giving them permission to perform the `escalate` verb on `roles` or `clusterroles` resources in the `rbac.authorization.k8s.io` API group +1. Attribuez-leur un rôle qui leur permet de créer/mettre à jour des objets Role ou ClusterRole, selon leurs besoins. +2. Leur accorder la permission d'inclure des autorisations spécifiques dans les rôles qu'ils créent/mettent à jour : + * implicitement, en leur accordant ces autorisations (s'ils tentent de créer ou de modifier un Role ou un ClusterRole avec des autorisations qui ne leur ont pas été accordées, la demande d'API sera interdite) + * ou explicitement, en leur donnant la permission de spécifier n'importe quelle permission dans un `Role` ou un `ClusterRole`, en leur donnant la permission d'exécuter le verbe `escalader` sur les `roles` ou les ressources `clusterroles` dans le groupe API `rbac.authorization.k8s.io`. -### Restrictions on role binding creation or update +### Restrictions à la création ou à la mise à jour de l'attribution de rôles -You can only create/update a role binding if you already have all the permissions contained in the referenced role -(at the same scope as the role binding) *or* if you have been authorized to perform the `bind` verb on the referenced role. -For example, if `user-1` does not have the ability to list Secrets cluster-wide, they cannot create a ClusterRoleBinding -to a role that grants that permission. To allow a user to create/update role bindings: +Vous ne pouvez créer/mettre à jour un lien de rôle que si vous disposez déjà de toutes les autorisations contenues dans le rôle référencé +(à la même portée que le lien de rôle) *ou* si vous avez été autorisé à exécuter le verbe `bind` sur le rôle référencé. +Par exemple, si l'`user-1` n'a pas la possibilité de lister les Secrets à l'échelle du cluster, il ne peut pas créer un ClusterRoleBinding +pour un rôle qui accorde cette permission. Pour permettre à un utilisateur de créer/mettre à jour des liaisons de rôle : -1. Grant them a role that allows them to create/update RoleBinding or ClusterRoleBinding objects, as desired. -2. Grant them permissions needed to bind a particular role: - * implicitly, by giving them the permissions contained in the role. - * explicitly, by giving them permission to perform the `bind` verb on the particular Role (or ClusterRole). +1. Accordez-leur un rôle qui leur permet de créer/mettre à jour des objets RoleBinding ou ClusterRoleBinding, selon leurs besoins. +2. Leur accorder les autorisations nécessaires pour lier un rôle particulier : + implicitement, en leur donnant les permissions contenues dans le rôle. + explicitement, en leur donnant la permission d'exécuter le verbe `bind` sur le rôle particulier (ou ClusterRole). -For example, this ClusterRole and RoleBinding would allow `user-1` to grant other users the `admin`, `edit`, and `view` roles in the namespace `user-1-namespace`: +Par exemple, ce ClusterRole et ce RoleBinding permettraient à `user-1` d'accorder à d'autres utilisateurs les rôles `admin`, `edit` et `view` dans l'espace de noms `user-1-namespace` : ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -960,42 +954,42 @@ subjects: name: user-1 ``` -When bootstrapping the first roles and role bindings, it is necessary for the initial user to grant permissions they do not yet have. -To bootstrap initial roles and role bindings: +Lors du démarrage des premiers rôles et des premières liaisons de rôles, il est nécessaire d'accorder à l'utilisateur initial des autorisations qu'il n'a pas encore. +Pour amorcer les premiers rôles et les premières liaisons de rôles : -* Use a credential with the "system:masters" group, which is bound to the "cluster-admin" super-user role by the default bindings. +* Utilisez un identifiant avec le groupe "system:masters", qui est lié au rôle de super-utilisateur "cluster-admin" par les liaisons par défaut. -## Command-line utilities +## Utilitaires de ligne de commande ### `kubectl create role` -Creates a Role object defining permissions within a single namespace. Examples: +Crée un objet Rôle définissant les autorisations au sein d'un espace de noms unique. Exemples : -* Create a Role named "pod-reader" that allows users to perform `get`, `watch` and `list` on pods: +* Créer un rôle nommé "pod-reader" qui permet aux utilisateurs d'effectuer les opérations `get`, `watch` et `list` sur les pods : ```shell kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods ``` -* Create a Role named "pod-reader" with resourceNames specified: +* Créer un rôle nommé "pod-reader" avec les resourceNames spécifiés: ```shell kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod ``` -* Create a Role named "foo" with apiGroups specified: +* Créer un rôle nommé "foo" avec les apiGroups spécifiés: ```shell kubectl create role foo --verb=get,list,watch --resource=replicasets.apps ``` -* Create a Role named "foo" with subresource permissions: +* Créer un rôle nommé "foo" avec des permissions de sous-ressources: ```shell kubectl create role foo --verb=get,list,watch --resource=pods,pods/status ``` -* Create a Role named "my-component-lease-holder" with permissions to get/update a resource with a specific name: +* Créer un rôle nommé "my-component-lease-holder" avec des permissions pour obtenir/mettre à jour une ressource avec un nom spécifique: ```shell kubectl create role my-component-lease-holder --verb=get,list,watch,update --resource=lease --resource-name=my-component @@ -1003,39 +997,39 @@ Creates a Role object defining permissions within a single namespace. Examples: ### `kubectl create clusterrole` -Creates a ClusterRole. Examples: +Crée un ClusterRole. Exemples: -* Create a ClusterRole named "pod-reader" that allows user to perform `get`, `watch` and `list` on pods: +* Créer un ClusterRole nommé "pod-reader" qui permet à l'utilisateur d'effectuer les opérations `get`, `watch` et `list` sur les pods : ```shell kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods ``` -* Create a ClusterRole named "pod-reader" with resourceNames specified: +* Créer un ClusterRole nommé "pod-reader" avec les resourceNames spécifiés : ```shell kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod ``` -* Create a ClusterRole named "foo" with apiGroups specified: +* Créer un ClusterRole nommé "foo" avec les apiGroups spécifiés: ```shell kubectl create clusterrole foo --verb=get,list,watch --resource=replicasets.apps ``` -* Create a ClusterRole named "foo" with subresource permissions: +* Créer un ClusterRole nommé "foo" avec des permissions de sous-ressources : ```shell kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status ``` -* Create a ClusterRole named "foo" with nonResourceURL specified: +* Créer un ClusterRole nommé "foo" avec un nonResourceURL spécifié: ```shell kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/* ``` -* Create a ClusterRole named "monitoring" with an aggregationRule specified: +* Créer un ClusterRole nommé "monitoring" avec une aggregationRule spécifiée: ```shell kubectl create clusterrole monitoring --aggregation-rule="rbac.example.com/aggregate-to-monitoring=true" @@ -1043,21 +1037,21 @@ Creates a ClusterRole. Examples: ### `kubectl create rolebinding` -Grants a Role or ClusterRole within a specific namespace. Examples: +Attribue un rôle ou un ClusterRole dans un espace de noms spécifique. Exemples: -* Within the namespace "acme", grant the permissions in the "admin" ClusterRole to a user named "bob": +* Dans le namespace "acme", accordez les permissions du rôle de cluster "admin" à un utilisateur nommé "bob": ```shell kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme ``` -* Within the namespace "acme", grant the permissions in the "view" ClusterRole to the service account in the namespace "acme" named "myapp": +* Dans le namespace "acme", accorder les permissions du CLusterRole "view" au compte de service du namespace "acme" nommé "myapp" : ```shell kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme ``` -* Within the namespace "acme", grant the permissions in the "view" ClusterRole to a service account in the namespace "myappnamespace" named "myapp": +* Dans le namespace "acme", accorder les permissions du ClusterRole "view" à un compte de service de le namespace "myappnamespace" nommé "myapp" : ```shell kubectl create rolebinding myappnamespace-myapp-view-binding --clusterrole=view --serviceaccount=myappnamespace:myapp --namespace=acme @@ -1065,21 +1059,21 @@ Grants a Role or ClusterRole within a specific namespace. Examples: ### `kubectl create clusterrolebinding` -Grants a ClusterRole across the entire cluster (all namespaces). Examples: +Attribue un ClusterRole à l'ensemble du cluster (tous les espaces de noms). Exemples: -* Across the entire cluster, grant the permissions in the "cluster-admin" ClusterRole to a user named "root": +* Sur l'ensemble du cluster, accordez les permissions du ClusterRole "cluster-admin" à un utilisateur nommé "root": ```shell kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root ``` -* Across the entire cluster, grant the permissions in the "system:node-proxier" ClusterRole to a user named "system:kube-proxy": +* Sur l'ensemble du cluster, accorder les permissions du ClusterRole "system:node-proxier" à un utilisateur nommé "system:kube-proxy": ```shell kubectl create clusterrolebinding kube-proxy-binding --clusterrole=system:node-proxier --user=system:kube-proxy ``` -* Across the entire cluster, grant the permissions in the "view" ClusterRole to a service account named "myapp" in the namespace "acme": +* Sur l'ensemble du cluster, accorder les permissions du ClusterRole "view" à un compte de service nommé "myapp" dans l'espace de noms "acme": ```shell kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp @@ -1087,55 +1081,55 @@ Grants a ClusterRole across the entire cluster (all namespaces). Examples: ### `kubectl auth reconcile` {#kubectl-auth-reconcile} -Creates or updates `rbac.authorization.k8s.io/v1` API objects from a manifest file. +Crée ou met à jour les objets de l'API `rbac.authorization.k8s.io/v1` à partir d'un fichier manifeste. -Missing objects are created, and the containing namespace is created for namespaced objects, if required. +Les objets manquants sont créés et le namespace contenant est créé pour les objets à namespace, si nécessaire. -Existing roles are updated to include the permissions in the input objects, -and remove extra permissions if `--remove-extra-permissions` is specified. +Les rôles existants sont mis à jour pour inclure les autorisations dans les objets d'entrée, +et supprimer les permissions supplémentaires si `--remove-extra-permissions` est spécifiée. -Existing bindings are updated to include the subjects in the input objects, -and remove extra subjects if `--remove-extra-subjects` is specified. +Les liaisons existantes sont mises à jour pour inclure les sujets dans les objets d'entrée, +et supprimer les sujets supplémentaires si `--remove-extra-subjects` est spécifiée. -Examples: +Exemples: -* Test applying a manifest file of RBAC objects, displaying changes that would be made: +* Test d'application d'un fichier manifeste d'objets RBAC, avec affichage des modifications apportées: ``` kubectl auth reconcile -f my-rbac-rules.yaml --dry-run=client ``` -* Apply a manifest file of RBAC objects, preserving any extra permissions (in roles) and any extra subjects (in bindings): +* Appliquer un fichier manifeste d'objets RBAC, en préservant toutes les autorisations supplémentaires (dans les rôles) et tous les sujets supplémentaires (dans les liaisons): ```shell kubectl auth reconcile -f my-rbac-rules.yaml ``` -* Apply a manifest file of RBAC objects, removing any extra permissions (in roles) and any extra subjects (in bindings): +* Appliquer un fichier manifeste d'objets RBAC, en supprimant toutes les autorisations supplémentaires (dans les rôles) et tous les sujets supplémentaires (dans les liaisons) : ```shell kubectl auth reconcile -f my-rbac-rules.yaml --remove-extra-subjects --remove-extra-permissions ``` -## ServiceAccount permissions {#service-account-permissions} +## Autorisations du ServiceAccount {#service-account-permissions} -Default RBAC policies grant scoped permissions to control-plane components, nodes, -and controllers, but grant *no permissions* to service accounts outside the `kube-system` namespace -(beyond discovery permissions given to all authenticated users). +Les règles RBAC par défaut accordent des autorisations aux composants du plan de contrôle, aux nœuds +et aux contrôleurs, mais n'accordent *aucunes permissions* aux comptes de service en dehors du namespace `kube-system` +(au-delà des autorisations de découverte accordées à tous les utilisateurs authentifiés). -This allows you to grant particular roles to particular ServiceAccounts as needed. -Fine-grained role bindings provide greater security, but require more effort to administrate. -Broader grants can give unnecessary (and potentially escalating) API access to -ServiceAccounts, but are easier to administrate. +Cela vous permet d'attribuer des rôles particuliers à des ServiceAccounts particuliers en fonction des besoins. +Des attributions de rôles plus fines offrent une plus grande sécurité, mais demandent plus d'efforts de gestion. +Des attributions plus larges peuvent donner un accès API inutile (et potentiellement escaladant) aux ServiceAccounts, +mais elles sont plus faciles à administrer. -In order from most secure to least secure, the approaches are: +Dans l'ordre, de la plus sûre à la moins sûre, les approches sont les suivantes: -1. Grant a role to an application-specific service account (best practice) +1. Attribuer un rôle à un compte de service spécifique à une application (meilleure pratique) - This requires the application to specify a `serviceAccountName` in its pod spec, - and for the service account to be created (via the API, application manifest, `kubectl create serviceaccount`, etc.). + Cela nécessite que l'application spécifie un `serviceAccountName` dans son pod spec, + et que le compte de service soit créé (via l'API, le manifeste de l'application, `kubectl create serviceaccount`, etc.). - For example, grant read-only permission within "my-namespace" to the "my-sa" service account: + Par exemple, accorder au compte de service "my-sa" l'autorisation de lecture seule dans "my-namespace": ```shell kubectl create rolebinding my-sa-view \ @@ -1144,16 +1138,16 @@ In order from most secure to least secure, the approaches are: --namespace=my-namespace ``` -2. Grant a role to the "default" service account in a namespace +2. Attribuer un rôle au compte de service "par défaut" dans un namespace - If an application does not specify a `serviceAccountName`, it uses the "default" service account. + Si une application ne spécifie pas de `serviceAccountName`, elle utilise le compte de service "par défaut". {{< note >}} - Permissions given to the "default" service account are available to any pod - in the namespace that does not specify a `serviceAccountName`. + Les autorisations accordées au compte de service "par défaut" sont disponibles pour tout pod + dans le namespace qui ne spécifie pas de `serviceAccountName`. {{< /note >}} - For example, grant read-only permission within "my-namespace" to the "default" service account: + Par exemple, accorder au compte de service "default" l'autorisation de lecture seule dans "my-namespace" : ```shell kubectl create rolebinding default-view \ @@ -1162,28 +1156,28 @@ In order from most secure to least secure, the approaches are: --namespace=my-namespace ``` - Many [add-ons](/docs/concepts/cluster-administration/addons/) run as the - "default" service account in the `kube-system` namespace. - To allow those add-ons to run with super-user access, grant cluster-admin - permissions to the "default" service account in the `kube-system` namespace. + De nombreux [modules complémentaires](/docs/concepts/cluster-administration/addons/) s'exécutent sous + le compte de service "default" dans le namespace du `kube-system`. + Pour permettre à ces modules complémentaires de fonctionner avec un accès de super-utilisateur, accordez les permissions cluster-admin + au compte de service "default" dans le namespace `kube-system`. - {{< caution >}} - Enabling this means the `kube-system` namespace contains Secrets - that grant super-user access to your cluster's API. - {{< /caution >}} + {{< attention >}} + Activer cela signifie que le namespace `kube-system `contient des Secrets + qui accordent un accès de super-utilisateur à l'API de votre cluster. + {{< /attention >}} ```shell kubectl create clusterrolebinding add-on-cluster-admin \ --clusterrole=cluster-admin \ --serviceaccount=kube-system:default ``` + +3. Attribuer un rôle à tous les comptes de service d'un namespace -3. Grant a role to all service accounts in a namespace + Si vous souhaitez que toutes les applications d'un namespace disposent d'un rôle, quel que soit le compte de service qu'elles utilisent, + vous pouvez attribuer un rôle au groupe de comptes de service de cet namespace. - If you want all applications in a namespace to have a role, no matter what service account they use, - you can grant a role to the service account group for that namespace. - - For example, grant read-only permission within "my-namespace" to all service accounts in that namespace: + Par exemple, accordez l'autorisation de lecture seule dans "my-namespace" à tous les comptes de service de cet namespace: ```shell kubectl create rolebinding serviceaccounts-view \ @@ -1192,11 +1186,11 @@ In order from most secure to least secure, the approaches are: --namespace=my-namespace ``` -4. Grant a limited role to all service accounts cluster-wide (discouraged) +4. Accorder un rôle limité à tous les comptes de service à l'échelle du cluster (déconseillé) - If you don't want to manage permissions per-namespace, you can grant a cluster-wide role to all service accounts. + Si vous ne souhaitez pas gérer les autorisations par namespace, vous pouvez accorder un rôle à l'échelle du cluster à tous les comptes de service. - For example, grant read-only permission across all namespaces to all service accounts in the cluster: + Par exemple, accordez l'autorisation de lecture seule dans tous les espaces de noms à tous les comptes de service du cluster : ```shell kubectl create clusterrolebinding serviceaccounts-view \ @@ -1204,15 +1198,15 @@ In order from most secure to least secure, the approaches are: --group=system:serviceaccounts ``` -5. Grant super-user access to all service accounts cluster-wide (strongly discouraged) +5. Accorder un accès de super-utilisateur à tous les comptes de service à l'échelle du cluster (fortement déconseillé). - If you don't care about partitioning permissions at all, you can grant super-user access to all service accounts. + Si vous ne vous souciez pas du tout des autorisations de partitionnement, vous pouvez accorder un accès de super-utilisateur à tous les comptes de service. - {{< warning >}} - This allows any application full access to your cluster, and also grants - any user with read access to Secrets (or the ability to create any pod) - full access to your cluster. - {{< /warning >}} + {{< attention >}} + Cela permet à n'importe quelle application d'avoir un accès complet à votre cluster, et accorde + également à n'importe quel utilisateur ayant un accès en lecture à Secrets (ou la possibilité de créer n'importe quel pod) + un accès complet à votre cluster. + {{< /attention >}} ```shell kubectl create clusterrolebinding serviceaccounts-cluster-admin \ @@ -1220,68 +1214,67 @@ In order from most secure to least secure, the approaches are: --group=system:serviceaccounts ``` -## Write access for EndpointSlices and Endpoints {#write-access-for-endpoints} +## Accès en écriture pour les EndpointSlices et les Endpoints {#write-access-for-endpoints} -Kubernetes clusters created before Kubernetes v1.22 include write access to -EndpointSlices (and Endpoints) in the aggregated "edit" and "admin" roles. -As a mitigation for [CVE-2021-25740](https://github.com/kubernetes/kubernetes/issues/103675), -this access is not part of the aggregated roles in clusters that you create using -Kubernetes v1.22 or later. +Les clusters Kubernetes créés avant Kubernetes v1.22 incluent un accès en écriture à +EndpointSlices (et Endpoints) dans les rôles agrégés "edit" et "admin". +Pour pallier à la [CVE-2021-25740](https://github.com/kubernetes/kubernetes/issues/103675), +cet accès ne fait pas partie des rôles agrégés dans les clusters que vous créez +à l'aide de Kubernetes v1.22 ou ultérieur. -Existing clusters that have been upgraded to Kubernetes v1.22 will not be -subject to this change. The [CVE -announcement](https://github.com/kubernetes/kubernetes/issues/103675) includes -guidance for restricting this access in existing clusters. +Les clusters existants qui ont été mis à niveau vers Kubernetes v1.22 ne seront pas soumis à ce changement. +L'[annonce du CVE](https://github.com/kubernetes/kubernetes/issues/103675) +comprend des recommandations pour restreindre cet accès dans les clusters existants. -If you want new clusters to retain this level of access in the aggregated roles, -you can create the following ClusterRole: +Si vous souhaitez que les nouveaux clusters conservent ce niveau d'accès dans les rôles agrégés, +vous pouvez créer le ClusterRole suivant : {{< codenew file="access/endpoints-aggregated.yaml" >}} -## Upgrading from ABAC +## Mise à niveau à partir d'ABAC -Clusters that originally ran older Kubernetes versions often used -permissive ABAC policies, including granting full API access to all -service accounts. +Les clusters qui exécutaient à l'origine d'anciennes versions de Kubernetes utilisaient +souvent des politiques ABAC permissives, notamment en accordant un accès API complet +à tous les comptes de service. -Default RBAC policies grant scoped permissions to control-plane components, nodes, -and controllers, but grant *no permissions* to service accounts outside the `kube-system` namespace -(beyond discovery permissions given to all authenticated users). +Les règles RBAC par défaut accordent des autorisations étendues aux composants du plan de contrôle, aux nœuds +et aux contrôleurs, mais n'accordent *aucune autorisation* aux comptes de service en dehors du namespace `kube-system` +(au-delà des autorisations de découverte accordées à tous les utilisateurs authentifiés). -While far more secure, this can be disruptive to existing workloads expecting to automatically receive API permissions. -Here are two approaches for managing this transition: +Bien que beaucoup plus sûre, cette solution peut perturber les charges de travail existantes qui s'attendent à recevoir automatiquement les autorisations de l'API. +Voici deux approches pour gérer cette transition: -### Parallel authorizers +### Autorisateurs parallèles -Run both the RBAC and ABAC authorizers, and specify a policy file that contains -the [legacy ABAC policy](/docs/reference/access-authn-authz/abac/#policy-file-format): +Exécutez les autorisateurs RBAC et ABAC, et spécifiez un fichier de stratégie qui contient +la [stratégie ABAC existante](/docs/reference/access-authn-authz/abac/#policy-file-format): ``` --authorization-mode=...,RBAC,ABAC --authorization-policy-file=mypolicy.json ``` -To explain that first command line option in detail: if earlier authorizers, such as Node, -deny a request, then the RBAC authorizer attempts to authorize the API request. If RBAC -also denies that API request, the ABAC authorizer is then run. This means that any request -allowed by *either* the RBAC or ABAC policies is allowed. +Pour expliquer en détail la première option de ligne de commande : si les autorisateurs précédents, tels que Node, +refusent une demande, l'autorisateur RBAC tente d'autoriser la demande d'API. Si RBAC +refuse également cette demande d'API, l'Authorizer ABAC est alors exécuté. Cela signifie que toute demande +autorisée par les stratégies RBAC ou ABAC est autorisée. -When the kube-apiserver is run with a log level of 5 or higher for the RBAC component -(`--vmodule=rbac*=5` or `--v=5`), you can see RBAC denials in the API server log -(prefixed with `RBAC`). -You can use that information to determine which roles need to be granted to which users, groups, or service accounts. +Lorsque kube-apiserver est exécuté avec un niveau de log de 5 ou plus pour le composant RBAC +(`--vmodule=rbac*=5 `ou `--v=5`), vous pouvez voir les refus RBAC dans le log du serveur API +(préfixé par `RBAC`). +Vous pouvez utiliser ces informations pour déterminer quels rôles doivent être accordés à quels utilisateurs, groupes ou comptes de service. -Once you have [granted roles to service accounts](#service-account-permissions) and workloads -are running with no RBAC denial messages in the server logs, you can remove the ABAC authorizer. +Une fois que vous avez [accordé des rôles aux comptes de service](#service-account-permissions) et que les charges de travail +fonctionnent sans message de refus RBAC dans les journaux du serveur, vous pouvez supprimer l'ABAC Authorizer. -### Permissive RBAC permissions +### Autorisations RBAC permissives -You can replicate a permissive ABAC policy using RBAC role bindings. +Vous pouvez répliquer une stratégie ABAC permissive à l'aide de liaisons de rôles RBAC. -{{< warning >}} -The following policy allows **ALL** service accounts to act as cluster administrators. -Any application running in a container receives service account credentials automatically, -and could perform any action against the API, including viewing secrets and modifying permissions. -This is not a recommended policy. +{{< attention >}} +La politique suivante permet à **TOUS** les comptes de service d'agir en tant qu'administrateurs de cluster. +Toute application s'exécutant dans un conteneur reçoit automatiquement +les informations d'identification du compte de service et peut effectuer n'importe quelle action sur l'API, y compris l'affichage des secrets et la modification des autorisations. +Cette stratégie n'est pas recommandée. ```shell kubectl create clusterrolebinding permissive-binding \ @@ -1290,7 +1283,7 @@ kubectl create clusterrolebinding permissive-binding \ --user=kubelet \ --group=system:serviceaccounts ``` -{{< /warning >}} +{{< /attention >}} -After you have transitioned to use RBAC, you should adjust the access controls -for your cluster to ensure that these meet your information security needs. +Après la transition vers l'utilisation de RBAC, vous devez ajuster les contrôles +d'accès pour votre cluster afin de vous assurer qu'ils répondent à vos besoins en matière de sécurité de l'information. From a01438f3353c8e18adfa55307fa2852611942210 Mon Sep 17 00:00:00 2001 From: vincent Date: Wed, 29 Mar 2023 00:36:04 +0000 Subject: [PATCH 14/14] Translation of rbac correct some grammar error --- .../docs/reference/access-authn-authz/rbac.md | 63 +++++++++---------- 1 file changed, 31 insertions(+), 32 deletions(-) diff --git a/content/fr/docs/reference/access-authn-authz/rbac.md b/content/fr/docs/reference/access-authn-authz/rbac.md index a6a9f10fef2..afb0b266e5d 100644 --- a/content/fr/docs/reference/access-authn-authz/rbac.md +++ b/content/fr/docs/reference/access-authn-authz/rbac.md @@ -23,12 +23,12 @@ utilisateurs individuels au sein de votre organisation. -L'autorisation RBAC utilise le `rbac.authorization.k8s.io` -{{< glossary_tooltip text="API group" term_id="api-group" >}} pour prendre les +L'autorisation RBAC utilise le {{< glossary_tooltip text="groupe d'API" term_id="api-group" >}} +`rbac.authorization.k8s.io` pour prendre les décisions d'autorisation, ce qui vous permet de configurer dynamiquement les politiques via l'API Kubernetes. -Pour activer RBAC, démarrez le {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} +Pour activer RBAC, démarrez l'{{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} avec l'indicateur `--authorization-mode` défini sur une liste séparée par des virgules qui inclut `RBAC` ; par exemple : ```shell @@ -44,15 +44,15 @@ ou les modifier, en utilisant des outils tels que `kubectl`, comme tout autre ob {{< caution >}} Ces objets, de par leur conception, imposent des restrictions d'accès. Si vous apportez des modifications -à un cluster au fur et à mesure de votre apprentissage, consultez +à un cluster au fur et à mesure de votre apprentissage, consultez la [prévention de l'escalade des privilèges et amorçage](#privilege-escalation-prevention-and-bootstrapping) pour comprendre comment ces restrictions peuvent vous empêcher d'effectuer certaines modifications. {{< /caution >}} -### Role and ClusterRole +### Role et ClusterRole Un _Role_ ou _ClusterRole_ RBAC contient des règles qui représentent un ensemble de permissions. -Les permissions sont purement additives (il n'y a pas de "deny" règles). +Les permissions sont purement additives (il n'y a pas de règles de "refus"). Un rôle définit toujours les autorisations dans un {{< glossary_tooltip text="namespace" term_id="namespace" >}} particulier; lorsque vous créez un Role, vous devez spécifier le namespace auquel il appartient. @@ -69,7 +69,7 @@ Les ClusterRoles ont plusieurs usages. Vous pouvez utiliser une ClusterRole pour Si vous souhaitez définir un rôle au sein d'un namespace, utilisez un Role; si vous souhaitez définir un rôle à l'échelle du cluster, utilisez un ClusterRole. -#### Role example +#### Exemple de Role Voici un exemple de rôle dans le namespace "default" qui peut être utilisé pour accorder un accès en lecture aux {{< glossary_tooltip text="pods" term_id="pod" >}}: @@ -86,22 +86,22 @@ rules: verbs: ["get", "watch", "list"] ``` -#### ClusterRole example +#### Exemple de ClusterRole -Une ClusterRole peut être utilisée pour accorder les mêmes permissions qu'un rôle. +Un ClusterRole peut être utilisé pour accorder les mêmes permissions qu'un Role. Étant donné que les ClusterRoles sont à l'échelle des clusters, vous pouvez également -les utiliser pour accorder l'accès à : +les utiliser pour accorder l'accès à: * des ressources à l'échelle du cluster (comme {{< glossary_tooltip text="nodes" term_id="node" >}}) * des endpoints non liés aux ressources (comme `/healthz`) * des ressources à namespaces (comme les pods), dans tous les namespaces. - Par exemple : vous pouvez utiliser un ClusterRole pour autoriser un utilisateur particulier à exécuter + Par exemple: vous pouvez utiliser un ClusterRole pour autoriser un utilisateur particulier à exécuter `kubectl get pods --all-namespaces` Voici un exemple de ClusterRole qui peut être utilisé pour accorder un accès en lecture à {{< glossary_tooltip text="secrets" term_id="secret" >}} dans un namespace particulier, -ou dans tous les namespaces (selon la façon dont il est [lié](#rolebinding-and-clusterrolebinding)) : +ou dans tous les namespaces (selon la façon dont il est [lié](#rolebinding-and-clusterrolebinding)): ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -233,13 +233,13 @@ Dans l'API Kubernetes, la plupart des ressources sont représentées et accessib comme `pods` pour un Pod. RBAC fait référence aux ressources en utilisant exactement le même nom que celui qui apparaît dans l'URL du endpoint de l'API concerné. Certaines API Kubernetes impliquent une -_subresource_, comme les logs d'un Pod. Une requête pour les logs d'un Pod ressemble à ceci : +_sous-ressource_, comme les logs d'un Pod. Une requête pour les logs d'un Pod ressemble à ceci : ```http GET /api/v1/namespaces/{namespace}/pods/{name}/log ``` -Dans ce cas, `pods` est le namespaced ressource pour les ressources Pods, +Dans ce cas, `pods` est la ressource à namespace pour les ressources Pods, et `log` est une sous-ressource de `pods`. Pour représenter cela dans un rôle RBAC, utilisez une barre oblique (`/`) pour délimiter la ressource et la sous-ressource. Pour permettre à un sujet de lire `pods` et d'accéder également à la sous-ressource `log` pour chacun de ces Pods, vous écrivez : @@ -258,7 +258,7 @@ rules: Vous pouvez également faire référence à des ressources par leur nom pour certaines demandes par le biais de la liste `resourceNames`. Lorsque cela est spécifié, les demandes peuvent être limitées à des instances individuelles d'une ressource. -Voici un exemple qui limite son sujet seulement à `get` ou `update` une +Voici un exemple qui limite son sujet à seulement `get` ou `update` une {{< glossary_tooltip term_id="ConfigMap" >}} nommée `my-configmap`: ```yaml @@ -456,7 +456,7 @@ rules: ``` Autoriser la lecture des ressources `"nodes"`dans le groupe central (parce -qu'un Node est à l'échelle-du-cluster, il doit être dans un ClusterRole +qu'un Nœud est à l'échelle-du-cluster, il doit être dans un ClusterRole lié à un ClusterRoleBinding pour être effectif) : ```yaml @@ -470,7 +470,7 @@ rules: ``` Autorise les requêtes GET et POST vers l'endpoint non ressource `/healthz` et -tous les subpaths (doit être dans un ClusterRole lié à un ClusterRoleBinding +tous les sous-chemins (doit être dans un ClusterRole lié à un ClusterRoleBinding pour être effectif) : ```yaml @@ -611,7 +611,6 @@ et met à jour les liaisons de rôles de cluster par défaut avec tous les sujet Cela permet au cluster de réparer les modifications accidentelles, et aide à maintenir les rôles et les liaisons de rôles à jour lorsque les autorisations et les sujets changent dans les nouvelles versions de Kubernetes. -Be aware that missing default permissions and subjects can result in non-functional clusters. Pour ne pas participer à cette reconciliation, définissez l'annotation `rbac.authorization.kubernetes.io/autoupdate` sur un rôle ou un rolebinding de cluster par défaut sur `false`. Sachez que les autorisations et les sujets par défaut manquants peuvent entraîner des clusters non fonctionnels. @@ -649,17 +648,17 @@ ne modifiez pas manuellement le rôle ou désactivez l'auto-reconciliation. system:basic-user -system:authenticated group +Groupe system:authenticated Permet à un utilisateur d'accéder en lecture seule aux informations de base le concernant. Avant la v1.14, ce rôle était également lié à system:unauthenticated par défaut. system:discovery -system:authenticated group +Groupe system:authenticated Permet un accès en lecture seule aux points de terminaison de découverte d'API nécessaires pour découvrir et négocier un niveau d'API. Avant la v1.14, ce rôle était également lié à l'option system:unauthenticated par défaut. system:public-info-viewer -system:authenticated and system:unauthenticated groups +Groupes system:authenticated et system:unauthenticated Permet un accès en lecture seule à des informations non sensibles sur le cluster. Introduit dans Kubernetes v1.14. @@ -696,7 +695,7 @@ metadata: cluster-admin -system:masters groupe +Groupe system:masters Permet au super-utilisateur d'effectuer n'importe quelle action sur n'importe quelle ressource. Lorsqu'il est utilisé dans un ClusterRoleBinding, il donne un contrôle total sur chaque ressource dans le cluster et dans tous les namespaces. Lorsqu'il est utilisé dans un RoleBinding, il donne un contrôle total sur chaque ressource dans le namespace du role binding, y compris le namespace lui-même. @@ -756,12 +755,12 @@ dans le namespace (une forme d'escalade des privilèges). system:kube-scheduler -utilisateur system:kube-scheduler +Utilisateur system:kube-scheduler Permet l'accès aux ressources requises par le composant {{< glossary_tooltip term_id="kube-scheduler" text="scheduler" >}}. system:volume-scheduler -system:kube-scheduler user +Utilisateur system:kube-scheduler Permet l'accès aux ressources de volume requises par le composant kube-scheduler. @@ -782,7 +781,7 @@ Le rôle system:node n'existe que pour la compatibilité avec les clust system:node-proxier -system:kube-proxy user +Utilisateur system:kube-proxy Permet l'accès aux ressources requises par le composant {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}. @@ -844,7 +843,7 @@ Il est couramment utilisé par les serveurs API complémentaires pour l'authenti system:monitoring -groupe system:monitoring +Groupe system:monitoring Autorise l'accès en lecture aux endpoints de monitoring du control-plane (c'est-à-dire les endpoints {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} liveness and readiness (/healthz, /livez, /readyz), les endpoints de contrôle de l'état individuel (/healthz/*, /livez/*, /readyz/*), et /metrics). Il convient de noter que les endpoints des contrôles de l'état individuel et les endpoints des mesures peuvent exposer des informations sensibles. @@ -1161,10 +1160,10 @@ Dans l'ordre, de la plus sûre à la moins sûre, les approches sont les suivant Pour permettre à ces modules complémentaires de fonctionner avec un accès de super-utilisateur, accordez les permissions cluster-admin au compte de service "default" dans le namespace `kube-system`. - {{< attention >}} + {{< caution >}} Activer cela signifie que le namespace `kube-system `contient des Secrets qui accordent un accès de super-utilisateur à l'API de votre cluster. - {{< /attention >}} + {{< /caution >}} ```shell kubectl create clusterrolebinding add-on-cluster-admin \ @@ -1202,11 +1201,11 @@ Dans l'ordre, de la plus sûre à la moins sûre, les approches sont les suivant Si vous ne vous souciez pas du tout des autorisations de partitionnement, vous pouvez accorder un accès de super-utilisateur à tous les comptes de service. - {{< attention >}} + {{< caution >}} Cela permet à n'importe quelle application d'avoir un accès complet à votre cluster, et accorde également à n'importe quel utilisateur ayant un accès en lecture à Secrets (ou la possibilité de créer n'importe quel pod) un accès complet à votre cluster. - {{< /attention >}} + {{< /caution >}} ```shell kubectl create clusterrolebinding serviceaccounts-cluster-admin \ @@ -1270,7 +1269,7 @@ fonctionnent sans message de refus RBAC dans les journaux du serveur, vous pouve Vous pouvez répliquer une stratégie ABAC permissive à l'aide de liaisons de rôles RBAC. -{{< attention >}} +{{< caution >}} La politique suivante permet à **TOUS** les comptes de service d'agir en tant qu'administrateurs de cluster. Toute application s'exécutant dans un conteneur reçoit automatiquement les informations d'identification du compte de service et peut effectuer n'importe quelle action sur l'API, y compris l'affichage des secrets et la modification des autorisations. @@ -1283,7 +1282,7 @@ kubectl create clusterrolebinding permissive-binding \ --user=kubelet \ --group=system:serviceaccounts ``` -{{< /attention >}} +{{< /caution >}} Après la transition vers l'utilisation de RBAC, vous devez ajuster les contrôles d'accès pour votre cluster afin de vous assurer qu'ils répondent à vos besoins en matière de sécurité de l'information.