installation de la version 2.0 du tableau de bord kubernetes et autorisation RBAC

Introduction au concept

1. apiserver

Pour les clusters k8s, apiserver est le seul point d'entrée pour le contrôle d'accès de l'ensemble du cluster, alors qui sont les clients qui interagissent avec apiserver?

Nous devons exécuter de nombreuses ressources de pod à l'intérieur du cluster, et les applications de ces pods doivent accéder à l'apiserver:

Par exemple, le conteneur coredns doit obtenir quelles ressources doivent être créées via l'apiserver; le tableau de bord est accessible dans le navigateur, puis nous pouvons ajouter, supprimer, modifier et vérifier les ressources à l'intérieur, créer d'autres pods ou espaces de noms, tout dont besoin d'interagir avec l'apiserver. L'utilisateur doit suivre le processus suivant pour accéder au cluster kubernetes: authentification d'identité -> autorisation

Ensuite, examinez les concepts spécifiques et les connaissances associées en matière d'authentification, d'autorisation et de contrôle d'accès.

2. Certification

2.1 L'authentification prend en charge plusieurs plug-ins

(1) Authentification par jeton:

Les deux parties ont une clé partagée. Créez un mot de passe sur le serveur et enregistrez-le. Lorsque le client se connecte, vous pouvez vous connecter avec ce mot de passe. Il s'agit d'une méthode d'authentification par clé symétrique; k8s fournit une interface de style reposante pour tous ses services. Ils sont tous fournis via le protocole http, de sorte que les informations d'authentification ne peuvent être transmises que par l'en-tête d'authentification du protocole http.La transmission de cet en-tête d'authentification est généralement appelée un jeton;

(2) Authentification SSL:

Pour l'accès k8s, l'authentification SSL permet au client de confirmer l'identité d'authentification du serveur. Lorsque nous communiquons avec le serveur, nous avons besoin que le serveur envoie un certificat. Nous devons confirmer si le certificat est signé par l'autorité de certification, s'il s'agit d'un CA approuvé par nos soins Signé, les informations de subj qu'il contient sont cohérentes avec les informations de l'hôte cible auxquelles nous accédons, il n'y a pas de problème, alors nous pensons que l'identité du serveur est authentifiée. La chose la plus importante dans k8s est que le serveur doit également authentifier les informations du client, et kubectl doit également avoir un certificat. Ce certificat est également un certificat signé par une autorité de certification reconnu par le serveur. Les deux parties doivent s'authentifier mutuellement pour obtenir le chiffrement. communication. Il s'agit de l'authentification SSL.

2.2 Compte sur kubernetes

Le client lance une demande à l'apiserver. L'apiserver doit déterminer si l'utilisateur dispose de l'autorité requise et si l'utilisateur peut effectuer l'opération correspondante via l'apiserver. Ensuite, quelles informations sont nécessaires pour identifier les informations utilisateur pour terminer l'accès associé contrôle de l'utilisateur?

kubectl explique pods.spec

Vous pouvez voir qu'il existe un champ serviceAccountName (nom du compte de service), c'est le compte que nous utilisons lorsque le pod se connecte à apiserver

Par conséquent, il existe deux types de comptes dans l'ensemble du cluster kubernetes, ServiceAccount (compte de service), compte d'utilisateur (compte d'utilisateur)

Compte d'utilisateur:

Une personne réelle, un compte auquel une personne peut se connecter, le client veut faire une demande à l'apiserver, et l'apiserver doit identifier si le client a l'autorisation demandée, alors différents utilisateurs auront des autorisations différentes, ce qui dépend de le compte d'utilisateur., Nom d'utilisateur appelé;

ServiceAccount

Il est conçu pour faciliter le processus dans le pod pour appeler l'API Kubernetes ou d'autres services externes. Il s'agit d'une ressource dans kubernetes

compte serviceaccount (sa): le compte utilisé pour se connecter à dashboad

compte utilisateur: il s'agit de l'utilisateur qui se connecte à la machine physique du k8s

ServiceAccount

Le compte de service est conçu pour faciliter le processus dans Pod pour appeler l'API Kubernetes ou d'autres services externes. Il est différent du compte utilisateur.

Compte d'utilisateur

1) Le compte utilisateur est conçu pour les personnes, tandis que le compte de service est conçu pour que les processus du Pod appellent l'API Kubernetes;

2) Le compte d'utilisateur est un espace de noms croisé, tandis que le compte de service est uniquement limité à l'espace de noms où il se trouve;

3) Chaque espace de noms créera automatiquement un compte de service par défaut

4) Après avoir ouvert le contrôleur d'admission ServiceAccount

Une fois que chaque pod est créé, il définira automatiquement spec.serviceAccount sur la valeur par défaut (sauf si un autre ServiceAccout est spécifié). Vérifiez que le compte de service référencé par le pod existe déjà ou refusez de créer. Si le pod ne spécifie pas ImagePullSecrets, ajoutez le ImagePullSecrets du compte de service sur le pod.

Lorsqu'un pod est créé, si aucun compte de service n'est spécifié, le système lui attribue automatiquement un compte de service par défaut sous le même espace de noms que le pod. Le compte utilisé pour la communication entre pod et apiserver est appelé serviceAccountName. comme suit:

kubectl obtenir des pods

kubectl récupère les pods frontend-4tbz4 -o yaml | grep "serviceAccountName

kubectl décrire les pods frontend-4tbz4

À partir de ce qui précède, nous pouvons voir que chaque pod aura un volume de stockage, qu'il soit défini ou non. Ce volume de stockage est le jeton du jeton par défaut - ***, qui correspond aux informations d'authentification du pod et du compte de service. Étant donné que les informations d'authentification sont des informations sensibles, elles doivent être stockées dans la ressource secrète et montées sur le pod sous la forme d'un volume de stockage. De cette manière, l'application exécutée dans le pod peut se connecter à l'apiserver via les informations du secret correspondant et terminer l'authentification. Chaque espace de noms a une ressource serviceaccount par défaut appelée default. Affichez le secret dans l'espace de noms et vous pouvez également voir le jeton par défaut correspondant. Autorisez tous les pods de l'espace de noms actuel à utiliser des informations d'authentification prédéfinies lors de la connexion à l'apiserver, afin d'assurer la communication entre les pods.

kubectl get sa

kubectl get sa -n kube-system

kubectl devient secret

kubectl get secret -n kube-system

Le compte de service par défaut ne peut obtenir que les attributs pertinents du pod actuel lui-même et ne peut pas observer les informations d'attribut pertinentes des autres pods d'espace de noms. Si vous souhaitez étendre un pod, supposons qu'un pod doit être utilisé pour gérer d'autres pods ou d'autres objets de ressource. Il est impossible d'obtenir les informations d'attribut pertinentes d'autres pods via le compte de service de son propre espace de noms. Pour le moment , vous devez créer manuellement un compte de service., Et le définir lors de la création d'un pod. Alors, comment définir serviceaccount? En fait, service accout appartient également à une ressource k8s et serviceAccount appartient également à une ressource k8s standard. Vous pouvez créer un serviceAccount. Après sa création, le pod que nous avons créé utilise serviceAccountName pour charger le serviceAccount que nous avons défini.

3. Autorisation

Si l'utilisateur est authentifié, il n'y a aucune autorité et certaines opérations d'autorisation ultérieures sont nécessaires, telles que l'ajout et la suppression de ressources, etc. Après kubernetes 1.6, il existe une autorisation RBAC (mécanisme de contrôle d'accès basé sur les rôles). mécanisme de contrôle. L'autorisation Kubernetes est basée sur la forme de plug-ins. Les plug-ins d'autorisation couramment utilisés sont les suivants:

Node (authentification de nœud) ABAC (contrôle d'accès basé sur les attributs) RBAC (contrôle d'accès basé sur les rôles) Webhook (contrôle d'accès basé sur le mécanisme de rappel http)

Laisser un utilisateur (Utilisateurs) jouer un rôle (Rôle), le rôle a des autorisations, de sorte que l'utilisateur dispose de telles autorisations, puis dans le mécanisme d'autorisation, seules les autorisations doivent être accordées à un rôle, et l'utilisateur obtiendra le autorisations du rôle correspondant. Pour obtenir le contrôle d'accès au rôle. Comme le montre la figure:

Dans le mécanisme d'autorisation de k8s, RBAC est adopté pour l'autorisation. La logique de travail consiste à définir l'autorité opérationnelle de l'objet à un rôle, puis à lier l'utilisateur au rôle, afin que l'utilisateur puisse obtenir l'autorité du rôle correspondant. . Si vous liez un rôle via la liaison de rôle, vous ne pouvez disposer d'autorisations que sur les ressources de l'espace de noms où se trouve la fonction de définition de rôle. Dans la figure ci-dessus, l'utilisateur1 est lié à rôle1 et ne dispose que des autorisations sur les ressources de l'espace de noms role1, et n'a aucune autorisation sur les ressources dans d'autres espaces de noms. Il appartient au niveau de l'espace de noms. De plus, k8s dispose également d'un mécanisme d'autorisation au niveau du cluster à cette fin, qui consiste à définir un rôle de cluster (ClusterRole), qui dispose d'autorisations opérationnelles pour toutes les ressources du cluster , afin que User2 soit lié à ClusterRole via ClusterRole, de sorte que User2 dispose de l'autorité d'exploitation du cluster. La relation entre Role, RoleBinding, ClusterRole et ClusterRoleBinding est la suivante:

Comme vous pouvez le voir sur la figure ci-dessus, la liaison de rôle peut être utilisée pour lier le rôle, la liaison de rôle peut être liée à clusterrole et clusterrolebinding peut être liée à clusterrole.

Ci-dessus, nous avons parlé de deux liaisons de rôle:

(1) L'utilisateur lie le rôle via la liaison de rôle (2) L'utilisateur lie le rôle de cluster via la liaison de cluster

Il existe un autre type: le rôle de cluster de liaison de liaison de rôle

S'il y a 6 espaces de noms et que les utilisateurs de chaque espace de noms doivent disposer des droits d'administrateur pour leurs propres espaces de noms, alors 6 rôles et liaisons de rôles doivent être définis, puis liés dans l'ordre. S'il y a plus d'espaces de noms, nous devons définir plus de rôle, c'est très gênant, nous introduisons donc le rôle de cluster, définissons un rôle de cluster, accordons toutes les autorisations au rôle de cluster, puis l'utilisateur se lie au rôle de cluster via la liaison de rôle, et il aura les autorisations d'administrateur de son propre espace de noms

Remarque: RoleBinding n'a que les autorisations correspondantes pour l'espace de noms actuel.

4. Contrôle d'accès

De manière générale, le contrôle d'accès n'est utilisé que pour définir d'autres opérations de contrôle de sécurité ultérieures une fois notre contrôle d'autorisation terminé, et complète le mécanisme d'autorisation, qui est mis en œuvre par une combinaison de plusieurs plug-ins. De manière générale, il est créé, supprimé, Modifié ou agi en tant que suppléments de procuration de temps à autre;

Installer et accéder au tableau de bord Kubernetes 2.0

Installer la version 2.0 de kubernetes-dashboard (interface utilisateur Web de kubernetes)

Téléchargez l'image kubernetes-dashboard sur chaque nœud du cluster k8s et décompressez-la avec docker load -i comme suit. L'adresse de l'image se trouve sur le disque réseau Baidu et peut être téléchargée comme suit:

链接：https://pan.baidu.com/s/1_1sBTSDw1FeKCncCLLi5dA提取码：eel8
链接：https://pan.baidu.com/s/1YtDQKrUuD6jH4VJ93zZcBg提取码：q6b8

docker load -i dashboard_2_0_0.tar.gz

docker load -i metrics-scrapter-1-0-1.tar.gz

Opérer sur le nœud master1

kubectl apply -f kubernetes-dashboard.yaml

Copiez le contenu du fichier kubernetes-dashboard.yaml à l'adresse de lien suivante https://raw.githubusercontent.com/luckylucky421/kubernetes1.17.3/master/kubernetes-dashboard.yaml

Vérifiez si le tableau de bord est correctement installé:

kubectl get pods -n kubernetes-dashboard

L'affichage est le suivant, indiquant que le tableau de bord est installé avec succès

NOM READY STATUS RESTARTS AGE dashboard-metrics-scraper-694557449d-8xmtf 1/1 Running 0 60s kubernetes-dashboard-5f98bdb684-ph9wg 1/1 Running 2 60s

Afficher le service à l'avant du tableau de bord

kubectl get svc -n kubernetes-dashboard

显示如下：

NAME                        TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE   dashboard-metrics-scraper   ClusterIP   10.100.23.9      <none>        8000/TCP   50s   kubernetes-dashboard        ClusterIP   10.105.253.155   <none>        443/TCP    50s

修改service type类型变成NodePort：

kubectl edit svc kubernetes-dashboard -n kubernetes-dashboard

把 type: ClusterIP变成 type: NodePort，保存退出即可

kubectl get svc -n kubernetes-dashboard

显示如下：

NAME                        TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)         AGEdashboard-metrics-scraper   ClusterIP   10.100.23.9      <none>        8000/TCP        3m59skubernetes-dashboard        NodePort    10.105.253.155   <none>        443:31175/TCP   4m

上面可看到service类型是NodePort，访问master1节点ip:31175端口即可访问kubernetes dashboard，我的环境需要输入如下地址

https://192.168.0.6:31775/

可看到出现了dashboard界面

1通过yaml文件里指定的默认的token登陆dashboard

1）查看kubernetes-dashboard名称空间下的secret

kubectl get secret -n kubernetes-dashboard

显示如下：

NAME                               TYPE                                  DATA   AGEdefault-token-vxd7t                kubernetes.io/service-account-token   3      5m27skubernetes-dashboard-certs         Opaque                                0      5m27skubernetes-dashboard-csrf          Opaque                                1      5m27skubernetes-dashboard-key-holder    Opaque                                2      5m27skubernetes-dashboard-token-ngcmg   kubernetes.io/service-account-token   3      5m27s

2）找到对应的带有token的kubernetes-dashboard-token-ngcmg

kubectl describe secret kubernetes-dashboard-token-ngcmg -n kubernetes-dashboard

显示如下：

...

...
token: eyJhbGciOiJSUzI1NiIsImtpZCI6IjZUTVVGMDN4enFTREpqV0s3cDRWa254cTRPc2xPRTZ3bk8wcFJBSy1JSzgifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlcm5ldGVzLWRhc2hib2FyZCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJrdWJlcm5ldGVzLWRhc2hib2FyZC10b2tlbi1uZ2NtZyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJrdWJlcm5ldGVzLWRhc2hib2FyZCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6ImYwMDFhNTM0LWE2ZWQtNGQ5MC1iMzdjLWMxMWU5Njk2MDE0MCIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDprdWJlcm5ldGVzLWRhc2hib2FyZDprdWJlcm5ldGVzLWRhc2hib2FyZCJ9.WQFE0ygYdKkUjaQjFFU-BeWqys07J98N24R_azv6f-o9AB8Zy1bFWZcNrOlo6WYQuh-xoR8tc5ZDuLQlnZMBSwl2jo9E9FLZuEt7klTfXf4TkrQGLCxzDMD5c2nXbdDdLDtRbSwQMcQwePwp5WTAfuLyqJPFs22Xi2awpLRzbHn3ei_czNuamWUuoGHe6kP_rTnu6OUpVf1txi9C1Tg_3fM2ibNy-NWXLvrxilG3x3SbW1A3G6Y2Vbt1NxqVNtHRRQsYCvTnp3NZQqotV0-TxnvRJ3SLo_X6oxdUVnqt3DZgebyIbmg3wvgAzGmuSLlqMJ-mKQ7cNYMFR2Z8vnhhtA

记住token后面的值，把下面的token值复制到浏览器token登陆处即可登陆：

eyJhbGciOiJSUzI1NiIsImtpZCI6IjZUTVVGMDN4enFTREpqV0s3cDRWa254cTRPc2xPRTZ3bk8wcFJBSy1JSzgifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlcm5ldGVzLWRhc2hib2FyZCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJrdWJlcm5ldGVzLWRhc2hib2FyZC10b2tlbi1uZ2NtZyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJrdWJlcm5ldGVzLWRhc2hib2FyZCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6ImYwMDFhNTM0LWE2ZWQtNGQ5MC1iMzdjLWMxMWU5Njk2MDE0MCIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDprdWJlcm5ldGVzLWRhc2hib2FyZDprdWJlcm5ldGVzLWRhc2hib2FyZCJ9.WQFE0ygYdKkUjaQjFFU-BeWqys07J98N24R_azv6f-o9AB8Zy1bFWZcNrOlo6WYQuh-xoR8tc5ZDuLQlnZMBSwl2jo9E9FLZuEt7klTfXf4TkrQGLCxzDMD5c2nXbdDdLDtRbSwQMcQwePwp5WTAfuLyqJPFs22Xi2awpLRzbHn3ei_czNuamWUuoGHe6kP_rTnu6OUpVf1txi9C1Tg_3fM2ibNy-NWXLvrxilG3x3SbW1A3G6Y2Vbt1NxqVNtHRRQsYCvTnp3NZQqotV0-TxnvRJ3SLo_X6oxdUVnqt3DZgebyIbmg3wvgAzGmuSLlqMJ-mKQ7cNYMFR2Z8vnhhtA

点击sing in登陆，显示如下，默认是只能看到default名称空间内容

2 创建管理员token，可查看任何空间权限

kubectl create clusterrolebinding dashboard-cluster-admin --clusterrole=cluster-admin --serviceaccount=kubernetes-dashboard:kubernetes-dashboard

1）查看kubernetes-dashboard名称空间下的secret

kubectl get secret -n kubernetes-dashboard

显示如下：

NAME                               TYPE                                  DATA   AGEdefault-token-vxd7t                kubernetes.io/service-account-token   3      5m27skubernetes-dashboard-certs         Opaque                                0      5m27skubernetes-dashboard-csrf          Opaque                                1      5m27skubernetes-dashboard-key-holder    Opaque                                2      5m27skubernetes-dashboard-token-ngcmg   kubernetes.io/service-account-token   3      5m27s

2）找到对应的带有token的kubernetes-dashboard-token-ngcmg

kubectl describe secret kubernetes-dashboard-token-ngcmg -n kubernetes-dashboard

显示如下：

...

记住token后面的值，把下面的token值复制到浏览器token登陆处即可登陆：

Cliquez sur chanter pour vous connecter, l'affichage est le suivant, cette fois vous pouvez voir et utiliser les ressources dans n'importe quel espace de noms