Vue imprimable multi-pages de cette section. .

Guides d'authentification

Guide d’authentification et de contrôle d’accès basé sur les rôles pour etcd

1: Authentification
2: Contrôle d'accès basé sur les rôles

1 - Authentification

Guide d’authentification d’un cluster etcd

auth,user,role pour l’authentification :

export ETCDCTL_API=3
ENDPOINTS=localhost:2379

etcdctl --endpoints=${ENDPOINTS} role add root
etcdctl --endpoints=${ENDPOINTS} role get root

etcdctl --endpoints=${ENDPOINTS} user add root
etcdctl --endpoints=${ENDPOINTS} user grant-role root root
etcdctl --endpoints=${ENDPOINTS} user get root

etcdctl --endpoints=${ENDPOINTS} role add role0
etcdctl --endpoints=${ENDPOINTS} role grant-permission role0 readwrite foo
etcdctl --endpoints=${ENDPOINTS} user add user0
etcdctl --endpoints=${ENDPOINTS} user grant-role user0 role0

etcdctl --endpoints=${ENDPOINTS} auth enable
# now all client requests go through auth

etcdctl --endpoints=${ENDPOINTS} --user=user0:123 put foo bar
etcdctl --endpoints=${ENDPOINTS} get foo
# permission denied, user name is empty because the request does not issue an authentication request
etcdctl --endpoints=${ENDPOINTS} --user=user0:123 get foo
# user0 can read the key foo
etcdctl --endpoints=${ENDPOINTS} --user=user0:123 get foo1

Note :

Il s’agit simplement d’un squelette qui doit être complété et mis à jour avec des informations supplémentaires sur l’authentification. Le texte ci-dessus n’est qu’un exemple de code.

2 - Contrôle d'accès basé sur les rôles

Guide d’authentification basique et de contrôle d’accès basé sur les rôles

Aperçu

L’authentification a été ajoutée à etcd 2.1. L’API v3 d’etcd a légèrement modifié l’API et l’interface utilisateur de la fonctionnalité d’authentification afin de mieux s’adapter au nouveau modèle de données. Ce guide vise à aider les utilisateurs à configurer une authentification basique et un contrôle d’accès basé sur les rôles dans etcd v3.

Utilisateurs et rôles spéciaux

Il existe un utilisateur spécial, root, et un rôle spécial, root.

Utilisateur `root`

L’utilisateur root, qui dispose d’un accès complet à etcd, doit être créé avant d’activer l’authentification. L’idée derrière l’utilisateur root est d’assurer des opérations administratives : gestion des rôles et des utilisateurs ordinaires. L’utilisateur root doit posséder le rôle root et est autorisé à modifier tout élément à l’intérieur d’etcd.

Rôle `root`

Le rôle root peut être attribué à tout utilisateur, en plus de l’utilisateur racine. Un utilisateur disposant du rôle root dispose à la fois d’un accès en lecture-écriture global et des autorisations pour mettre à jour la configuration d’authentification du cluster. En outre, le rôle root accorde les privilèges nécessaires à la maintenance générale du cluster, notamment la modification de la composition du cluster, la défragmentation du magasin et la prise d’instantanés.

Travail avec les utilisateurs

Le sous-commande user pour etcdctl gère toutes les opérations relatives aux comptes utilisateurs.

Une liste des utilisateurs peut être obtenue avec :

$ etcdctl user list

Créer un utilisateur est aussi simple que

$ etcdctl user add myusername

La création d’un nouvel utilisateur demande de saisir un nouveau mot de passe. Le mot de passe peut être fourni depuis l’entrée standard lorsque l’option --interactive=false est utilisée. --new-user-password peut également être utilisé pour fournir le mot de passe.

La création d’un utilisateur qui ne peut pas être authentifié avec un mot de passe est également possible, comme indiqué ci-dessous :

$ etcdctl user add myusername --no-password

Un tel utilisateur ne peut être authentifié que par TLS Common Name .

Note

etcd ne prend pas en charge l’authentification avec un mot de passe vide via --user username:. Par exemple, un utilisateur créé avec un mot de passe vide, tel que etcdctl user add anonymous:'', ne peut pas s’authentifier par des requêtes username/password et les requêtes telles que etcdctl --user anonymous: get foo échouent avec user name is empty.

Les rôles peuvent être attribués ou retirés à un utilisateur avec :

$ etcdctl user grant-role myusername foo
$ etcdctl user revoke-role myusername bar

Les paramètres de l’utilisateur peuvent être inspectés à l’aide de :

$ etcdctl user get myusername

Et le mot de passe d’un utilisateur peut être modifié avec

$ etcdctl user passwd myusername

Changer le mot de passe provoquera une nouvelle demande de mot de passe. Le mot de passe peut être fourni depuis l’entrée standard lorsque l’option --interactive=false est utilisée.

Supprimez un compte avec :

$ etcdctl user delete myusername

Travail avec les rôles

Le sous-commande role pour etcdctl gère toutes les opérations relatives aux contrôles d’accès pour des rôles spécifiques, tels qu’ils ont été attribués à des utilisateurs individuels.

Lister les rôles avec :

$ etcdctl role list

Créez un nouveau rôle avec :

$ etcdctl role add myrolename

Un rôle n’a pas de mot de passe ; il définit simplement un nouvel ensemble de droits d’accès.

Les rôles ont accès à une clé unique ou à une plage de clés.

La plage peut être spécifiée sous la forme d’un intervalle [clé_de_depart, clé_de_fin) où la clé_de_depart doit être strictement inférieure à la clé_de_fin selon un ordre alphabétique.

L’accès peut être accordé en lecture, écriture ou les deux, comme dans les exemples suivants :

# Give read access to a key /foo
$ etcdctl role grant-permission myrolename read /foo

# Give read access to keys with a prefix /foo/. The prefix is equal to the range [/foo/, /foo0)
$ etcdctl role grant-permission myrolename --prefix=true read /foo/

# Give write-only access to the key at /foo/bar
$ etcdctl role grant-permission myrolename write /foo/bar

# Give full access to keys in a range of [key1, key5)
$ etcdctl role grant-permission myrolename readwrite key1 key5

# Give full access to keys with a prefix /pub/
$ etcdctl role grant-permission myrolename --prefix=true readwrite /pub/

Pour voir ce qui est accordé, nous pouvons consulter le rôle à tout moment :

$ etcdctl role get myrolename

La révocation des autorisations s’effectue de la même manière logique :

$ etcdctl role revoke-permission myrolename /foo/bar

Comme pour supprimer un rôle entièrement :

$ etcdctl role delete myrolename

Activer l’authentification

Les étapes minimales pour activer l’authentification sont les suivantes. L’administrateur peut configurer les utilisateurs et les rôles avant ou après l’activation de l’authentification, selon son choix.

Assurez-vous que l’utilisateur racine est créé :

$ etcdctl user add root
Password of root:

Activer l’authentification :

$ etcdctl auth enable

Après cela, etcd fonctionne avec l’authentification activée. Pour la désactiver pour une raison quelconque, utilisez la commande inverse :

$ etcdctl --user root:rootpw auth disable

Portée de sécurité de l’authentification

Lorsque l’authentification est activée avec etcdctl auth enable, elle protège les opérations de l’API gRPC V3 (get, put, delete, surveillance, etc.).

Les points de terminaison HTTP /metrics et /health fonctionnent sur un gestionnaire distinct et ne sont pas protégés par l’authentification RBAC V3. Ce design permet à Prometheus et aux équilibreurs de charge de récupérer les métriques sans nécessiter d’authentification gRPC, tout en maintenant la protection des données clé-valeur.

Pour sécuriser ces points de visualisation :

Activez le mTLS avec --cert-file, --key-file et --client-cert-auth
Ou liez les métriques à une interface privée en utilisant --listen-metrics-urls
Ou utilisez des règles de réseau policies/firewall pour restreindre l’accès

Utilisation de `etcdctl` pour l’authentification

etcdctl prend en charge un indicateur similaire à curl pour l’authentification.

$ etcdctl --user user:password get foo

Le mot de passe peut être fourni à partir d’une invite :

$ etcdctl --user user get foo

Le mot de passe peut également être fourni via une option de ligne de commande --password :

$ etcdctl --user user --password password get foo

Sinon, toutes les commandes etcdctl restent identiques. Les utilisateurs et rôles peuvent toujours être créés et modifiés, mais nécessitent une authentification par un utilisateur disposant du rôle root.

Utilisation du nom commun TLS

À compter de la version v3.2, si un serveur etcd est lancé avec l’option --client-cert-auth=true, le champ Common Name (CN) du certificat TLS du client sera utilisé comme utilisateur etcd. Dans ce cas, le nom commun sert à authentifier l’utilisateur, et le client n’a pas besoin de mot de passe. Notez que si les deux conditions suivantes sont remplies : 1. --client-cert-auth=true est fourni et le CN est fourni par le client, et 2. le nom d’utilisateur et le mot de passe sont fournis par le client, l’authentification basée sur le nom d’utilisateur et le mot de passe est prioritaire. Notez que cette fonctionnalité ne peut pas être utilisée avec gRPC-proxy ni avec gRPC-gateway. Cela est dû au fait que gRPC-proxy termine la connexion TLS provenant de son client, si bien que tous les clients partagent un certificat du proxy. gRPC-gateway utilise une connexion TLS interne pour transformer une requête HTTP en requête gRPC, ce qui entraîne la même limitation. Par conséquent, les clients ne peuvent pas transmettre correctement leur CN au serveur. gRPC-proxy provoquera une erreur et s’arrêtera si le certificat fourni a un CN non vide. gRPC-proxy renvoie une erreur indiquant que le client possède un CN non vide dans son certificat.

Remarques sur la force du mot de passe

Les API etcdctl et etcd n’imposent aucune longueur de mot de passe particulière lors de la création d’un utilisateur ou de la mise à jour de son mot de passe. Il incombe à l’administrateur d’appliquer ces exigences. Pour réduire les risques liés aux mots de passe faibles, utilisez l’authentification fondée sur le nom commun TLS ainsi que des utilisateurs créés avec l’option --no-password.