K8S学习之serviceacount~RBAC授权

已于 2022-04-02 20:08:20 修改
阅读量1.4k 收藏 4
点赞数 1
分类专栏： kubenetes 文章标签： kubernetes docker linux
于 2022-01-25 22:17:42 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_60092693/article/details/122521981
版权

第一部分、认证

kubernetes上的账号

kubectl explain pods.spec可以看到有一个字段serviceAccountName（服务账号名称），这个就是我们pod连接apiserver时使用的账号，整个kubernetes集群中的账号有两类，ServiceAccount（服务账号），User account（用户账号）

User account：实实在在现实中的人，人可以登陆的账号，客户端想要对apiserver发起请求，apiserver要识别这个客户端是否有请求的权限，那么不同的用户就会有不同的权限，靠用户账号表示，叫做username，这个是登陆k8s物理机器的用户

ServiceAccount：方便Pod里面的进程调用Kubernetes API或其他外部服务而设计的，是kubernetes中的一种资源。service account仅局限它所在的namespace，当创建 pod 的时候，如果没有指定一个 serviceaccount，系统会自动在与该pod 相同的 namespace 下为其指派一个default service account。而pod和apiserver之间进行通信的账号，称为serviceAccountName。

[root@master ~]# vim read-pod.yaml
kind: Pod
apiVersion: v1
metadata:
  name: read-pod
spec:
  containers:
  - name: read-pod
    image: nginx
    imagePullPolicy: IfNotPresent
[root@master ~]# kubectl apply -f read-pod.yaml
pod/read-pod created
[root@master ~]# kubectl get pod
NAME                              READY   STATUS    RESTARTS   AGE
read-pod                          1/1     Running   0          4s
[root@master ~]# kubectl get pod read-pod -oyaml |grep service
  serviceAccount: default
  serviceAccountName: default
[root@master ~]# kubectl get namespaces
NAME                   STATUS   AGE
default                Active   1d
[root@master ~]# kubectl get sa
NAME              SECRETS   AGE
default           1         8d
[root@master ~]# kubectl get sa -n kube-system
NAME                                 SECRETS   AGE
bootstrap-signer                     1         1d
calico-node                          1         1d
certificate-controller               1         1d
clusterrole-aggregation-controller   1         1d
coredns                              1         1d
...
[root@master ~]# kubectl get secrets
NAME                          TYPE                                  DATA   AGE
default-token-86dcd           kubernetes.io/service-account-token   3      1d
[root@master ~]# kubectl get secret -n kube-system
NAME                                          TYPE      DATA   AGE   
bootstrap-signer-token-j9nf6             kubernetes.io/service-account-token   
calico-node-token-8fdpx                  kubernetes.io/service-account-token   
certificate-controller-token-8c7rb       kubernetes.io/service-account-token  
...

创建一个serviceacount

[root@master ~]# kubectl explain sa
[root@master ~]# kubectl create serviceaccount test
serviceaccount/test created
[root@master ~]# kubectl get sa
NAME              SECRETS   AGE
default           1         1d
test              1         12s
[root@master ~]# kubectl describe sa test
Name:                test
Namespace:           default
Labels:              <none>
Annotations:         <none>
Image pull secrets:  <none>
Mountable secrets:   test-token-lfr9f
Tokens:              test-token-lfr9f
Events:              <none>

生成serviceaccount时会创建secret，通过describe secret来查看 token。这个token能够登陆k8s，能认证到k8s，但是不能做别的事情，想要做其他事情，需要授权

[root@master ~]# kubectl get secrets
NAME                          TYPE                                  DATA   AGE
default-token-86dcd           kubernetes.io/service-account-token   3      1d
test-token-lfr9f              kubernetes.io/service-account-token   3     3m34s
[root@master ~]# kubectl describe secrets test-token-lfr9f
Name:         test-token-lfr9f
Namespace:    default
Labels:       <none>
Annotations:  kubernetes.io/service-account.name: test
              kubernetes.io/service-account.uid: b02d013f-dfa4-46d2-a8a2-6d0f27402a7b

Type:  kubernetes.io/service-account-token

Data
====
ca.crt:     1025 bytes
namespace:  7 bytes
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6InlPVVR4aFY3OEgzbWdkZnVFM2kzMlMiOiJrdWJlcm5....

[root@master ~]# kubectl config view
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://192.168.1.11:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: kubernetes-admin
  name: kubernetes-admin@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: kubernetes-admin
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED

第二部分、授权
Kubernetes的授权是基于插件形式的，主要的授权插件RBAC（基于角色的访问控制）
两个角色绑定：

（1）用户通过rolebinding绑定role
（2）用户通过clusterrolebinding绑定clusterrole
（3）rolebinding绑定clusterrole

每个名称空间的用户都需要对自己的名称空间有管理员权限，role和rolebinding绑定，就会拥有自己名称空间的管理员权限了。如果名称空间更多，我们需要定义更多的role，这个是很麻烦的，所以我们引入clusterrole，对clusterrole授予所有权限，然后用户通过rolebinding绑定到clusterrole，就会拥有该名称空间的管理员权限了

[root@master ~]# kubectl get role -n kube-system
NAME                                             CREATED AT
extension-apiserver-authentication-reader        2021-12-10T14:18:31Z
kube-proxy                                       2021-12-10T14:18:33Z
kubeadm:kubelet-config-1.18                      2021-12-10T14:18:32Z

[root@master ~]# kubectl get rolebinding -n kube-system
NAME                 ROLE                    AGE
kube-proxy       Role/kube-proxy             18d
kubeadm:kubelet-config-1.18      Role/kubeadm:kubelet-config-1.18       18d
kubeadm:nodes-kubeadm-config    Role/kubeadm:nodes-kubeadm-config       18d

[root@master ~]# kubectl get clusterrole
NAME                                      CREATED AT
admin                  		2021-12-10T14:18:31Z
calico-node                	2021-12-10T15:05:47Z
cluster-admin               2021-12-10T14:18:31Z

[root@master ~]# kubectl get clusterrolebinding
NAME                   ROLE                              AGE
calico-node         ClusterRole/calico-node              18d
cluster-admin       ClusterRole/cluster-admin            18d

kubernetes 中的认证机制 自己多读文档学吧

通过token登陆dashboard界面

[root@master ~]# kubectl get pods -n kubernetes-dashboard
NAME                                         READY   STATUS    RESTARTS   AGE
dashboard-metrics-scraper-694557449d-czn7l   1/1     Running   14         18d
kubernetes-dashboard-5f98bdb684-qxqz4        1/1     Running   17         18d
[root@master ~]# kubectl get svc -n kubernetes-dashboard
NAME                   TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)       
dashboard-metrics-scraper   ClusterIP   10.103.54.188   <none>        8000/TCP 
kubernetes-dashboard    NodePort    10.109.53.21    <none>        443:31152/TCP

浏览器访问https://192.168.1.11:31152/选择tokent登入dashboard
（1）使用default的token登入,会发现没有任何权限

[root@master ~]# kubectl get sa
NAME              SECRETS   AGE
default           1         18d
[root@master ~]# kubectl describe sa default
Name:                default
Namespace:           default
Labels:              <none>
Annotations:         <none>
Image pull secrets:  <none>
Mountable secrets:   default-token-86dcd
Tokens:              default-token-86dcd
Events:              <none>
[root@master ~]# kubectl describe secrets default-token-86dcd
Name:         default-token-86dcd
Namespace:    default
Labels:       <none>
Annotations:  kubernetes.io/service-account.name: default
              kubernetes.io/service-account.uid: 22452d24-2c52-450e-9bc0-b2bee660aaf7

Type:  kubernetes.io/service-account-token

Data
====
ca.crt:     1025 bytes
namespace:  7 bytes
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6InlPVVR4aFY3OEgzbWdkZnVFM2kzMlMyW...

(2)使用kubernetes-dashboard的token登入

[root@master ~]# kubectl get ns
NAME                   STATUS   AGE
kubernetes-dashboard   Active   18d
[root@master ~]# kubectl get sa -n kubernetes-dashboard
NAME                   SECRETS   AGE
kubernetes-dashboard   1         18d
[root@master ~]# kubectl get secrets -n kubernetes-dashboard
NAME                               TYPE                              DATA   AGE
kubernetes-dashboard-token-dkd5b   kubernetes.io/service-account-token 3  18d
[root@master ~]# kubectl describe secrets kubernetes-dashboard-token-dkd5b -n kubernetes-dashboard
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6InlPVVR4aFYNNUVReX

创建新的serviceaccount用户lucky，做rolebinding绑定，登入

[root@master ~]# kubectl create namespace lucky
[root@master ~]# kubectl create serviceaccount lucky-admin -n lucky
[root@master ~]# kubectl create rolebinding lucky-admin-rolebinding -n lucky --clusterrole=cluster-admin --serviceaccount=lucky:lucky-admin
创建lucky-admin-rolebinding的rolebinding，clusterrole为cluster-admin(这个role可以查如下)，serviceaccount为lucky命名空间下的lucky-admin
[root@master ~]# kubectl get  clusterrole
NAME                              CREATED AT
cluster-admin                  2021-12-10T14:18:31Z
[root@master ~]# kubectl get secret -n lucky
NAME                      TYPE                                  DATA   AGE
default-token-gwzv7       kubernetes.io/service-account-token   3      60s
lucky-admin-token-zh7xd   kubernetes.io/service-account-token   3      49s
[root@master ~]# kubectl describe secret lucky-admin-token-zh7xd -n lucky
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6InlPVVR4aFY3OEgzbWdkZnVFM2kzMlMyWGFC...

刷新页面用lucky的token登入，命名空间输入lucky可以看到secret，也可以创建pod等，但是对于别的空间，没有任何权限。
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

[root@master ~]# kubectl get pod -n lucky
NAME       READY   STATUS    RESTARTS   AGE
read-pod   1/1     Running   0          3m30s

给lucky做clusterrolebinding，clusterrolebinding不需要指定命名空间

[root@master ~]# kubectl create clusterrolebinding lucky-admin-clusterrole  --clusterrole=cluster-admin --serviceaccount=lucky:lucky-admin
[root@master ~]# kubectl get sa -n lucky
NAME          SECRETS   AGE
lucky-admin   1         45m
[root@master ~]# kubectl get secrets -n lucky
NAME                      TYPE                                  DATA   AGE
lucky-admin-token-zh7xd   kubernetes.io/service-account-token   3      45m
[root@master ~]# kubectl describe secrets lucky-admin-token-zh7xd -n lucky
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6InlPVVR4aFY3OEgzbWdkZnVFM2kzMlMyWGFCNk1mUjhNNUVReXd

再次用lucky的token登入发现，拥有了所有的权限
在这里插入图片描述

使用kubeconfig登入

cd /etc/kubernetes/pki

（1）创建cluster

[root@master ~]# cd /etc/kubernetes/pki/
[root@master pki]# kubectl config set-cluster kubernetes --certificate-authority=./ca.crt --server="https://192.168.1.11:6443" --embed-certs=true --kubeconfig=/root/lucky-admin.conf

在这里插入图片描述

（2）创建credentials时需要使用上面我门创建的token信息，创建credentials。

[root@master pki]# kubectl get secret -n lucky
NAME                      TYPE                                  DATA   AGE
lucky-admin-token-zh7xd   kubernetes.io/service-account-token   3      75m
[root@master pki]# DEF_NS_ADMIN_TOKEN=$(kubectl get secret lucky-admin-token-zh7xd  -n lucky -o jsonpath={.data.token}|base64 -d)
[root@master pki]# kubectl config set-credentials lucky --token=$DEF_NS_ADMIN_TOKEN --kubeconfig=/root/lucky-admin.conf

在这里插入图片描述

（3）创建context

[root@master pki]# kubectl config set-context lucky@kubernetes --cluster=kubernetes --user=lucky --kubeconfig=/root/lucky-admin.conf
Context "lucky@kubernetes" created.

在这里插入图片描述
（4）切换context的current-context是lucky@kubernetes

[root@master pki]# kubectl config use-context lucky@kubernetes --kubeconfig=/root/lucky-admin.conf

在这里插入图片描述

将/root/lucky-admin.conf拷贝到桌面。浏览器选择kubeconfig登录，此时能够成功登录
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

daydayup9527
关注
  • 1
    点赞
  • 踩
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
K8S之 metrics-server 组件
06-17
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: metrics-server roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:aggregated-metrics-...
Kubernetes详解（四十九）——ServiceAccount实战
永远是少年
05-09 1907
今天继续给大家介绍Linux运维相关知识，本文主要内容是ServiceAccount实战。 一、ServiceAccount创建 二、ServiceAccount应用
k8s学习第20天--service account
qq_34893654的博客
05-04 202
在 Kubernetes 中，Service Account 是一种用于在 Pod 内运行的特殊用户身份。每个 Service Account 都会分配一个唯一的名称和一个对应的 API 对象。使用 Service Account 可以轻松管理 Pod 的身份验证和授权问题。在默认情况下，Kubernetes 会为每个 Namespace 分配一个默认的 Service Account，使得所有在该 Namespace 内创建的 Pod 都可以自动使用该 Service Account 进行身份验证。
APIServer 认证 ServiceAccount
最新发布
小楼一夜听春雨，深巷明朝卖杏花
07-12 1861
的SerivceAccount后，我们来看一下这个ServiceAccount的内容。我们按照前面yaml文件创建Pod，那么apiserver将会把该ServiceAccount的Secret挂载到Pod的路径。然后，然后apiserver的serviceaccount认证器拿到这个ServiceAccountToken后，利用参数。从外部访问Apiserver的安全端口时，客户端需要携带一个身份凭证，能够让apiserver认证为某个用户以及所属的组。我们来看一下这个Secret的内容，如下。
Kubernetes_认证授权_ServiceAccount_服务账号全解析
毛毛的专栏
10-23 2042
梳理出ServiceAccount服务账号一条线
K8S ServiceAccount
summer_fish的专栏
08-07 2036
一、ServiceAccount通常被用于授权Pod与集群中的其他资源和服务进行通信，以及访问一些需要权限的操作。ServiceAccount为Pod提供了一个身份，使得Pod能够与Kubernetes API进行交互。Kubernetes API会根据ServiceAccount的身份进行授权判断。通过ServiceAccount，Kubernetes管理员可以对Pod进行权限控制，限制它们能够访问的资源和操作，从而增强集群的安全性。
k8s之ServiceAccount
热门推荐
weixin_37337210的博客
01-17 1万+
导读 上一篇说了k8s的RBAC授权模式，今天就来简单看一下其中涉及到的ServiceAccount。 简介 k8s创建两套独立的账号系统，原因如下： （1）User账号给用户用，Service Account是给Pod里的进程使用的，面向的对象不同 （2）User账号是全局性的，Service Account则属于某个具体的Namespace （3）User账号是与后端的用户数据库同步的，创建一个新用户通常要走一套复杂的业务流程才能实现，Service Account的创建则需要极轻量级的实现
k8s学习资源.zip
06-05
k8s学习资源.zip这个压缩包显然包含了丰富的资料，旨在帮助学习者深入理解和掌握Kubernetes的核心概念和技术。 首先，我们可以从“k8s学习资源”这个标题推测，这份资料可能是围绕Kubernetes的基础知识、实战操作...
个人学习k8s相关资料
06-01
这个“个人学习k8s相关资料”压缩包很可能是包含了一系列的学习资源，帮助你深入理解和掌握Kubernetes的核心概念和技术。下面将详细阐述K8s的关键知识点。 一、Kubernetes基础 1. **容器化**：Kubernetes建立在...
k8s学习资料.zip
02-07
本资料包包含了丰富的k8s学习资源，帮助你深入理解和掌握这个强大的工具。 1. **Kubernetes基本概念** - **Pod**：Kubernetes的基本调度单元，它封装了一个或多个紧密相关的容器。 - **Service**：定义了访问Pods...
在k8s中部署prometheus的镜像
03-23
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: prometheus rules: - apiGroups: [""] resources: ["services", "pods", "endpoints", "nodes"] verbs: ["get", "list", "watch"]...
K8s中Service Account和RBAC
l1727377的博客
12-16 2412
①.ServiceAccount（服务账户）是Kubernetes集群中的一种资源对象，用于为Pod或其他资源提供身份验证和授权，以便它们能够与Kubernetes API进行交互。②.ServiceAccount是Kubernetes中用于管理Pod身份验证和授权的重要资源，它使得Pod能够在集群中具有独立的身份，从而实现更精细的权限控制和安全策略。③. Service Account它并不是给kubernetes集群的用户使用的，而是给pod里面的进程使用的，它为pod提供必要的身份认证。
k8s serviceAccountName填写后应用没有进行挂载问题处理
w2481296的博客
02-05 1603
k8s机制: 使用yaml文件创建应用时，填写serviceAccountName后，pod会自动挂载serviceAccount所创建的密钥。pod默认挂载default密钥. 问题： 使用Java方式创建应用，填写serviceAccountName后，pod密钥无法挂载。 问题定位与解决： 经过创建日志查到json确实填写了serviceAccountName。 后来经过资料查询，pod里有个字段automountServiceAccountToken 该字段作用决定serviceAccountNa
详解 ServiceAccount -- k8s的服务账号是如何工作的？
千里之行
12-17 7773
Kubernetes 的 Service Account 是如何工作的
2020-09-22 kubernetes dashboard 的登录
Pancras的博客
03-09 1806
登录kubernetes dashboard 如图1-1所示，kubernetes dashboard提供了两种登录方式： kubeconfig 令牌 下面将对这两种登录方式进行介绍。 令牌登录 令牌登录就是使用serviceAccount账户的token值登录，在kubernetes中，每个serviceAccount(简称sa)账户都对应一个token值，我们就可以使用该值进行登录。需要注意的是，使用token登录只具有view权限，不能在dashboard中删除或创建pod。 #########
k8s、ServiceAccount权限详解、RBAC 详解(基于角色的访问控制)，常用操作指令
mingqing的博客
11-29 4851
文章目录Service Account应用示例RBAC 详解(基于角色的访问控制)创建一个角色（role）---权限实验二常用操作指令 Service Account应用示例 概念图权限关系 我自己的理解就是，Service Account就是pod的权限 1、创建serviceaccount [root@kub-k8s-master ~]# kubectl create serviceaccount mysa serviceaccount/mysa created 2、查看mysa [root@kub
Kubernetes—Serviceaccount
屈帅波的技术博客
11-27 555
1.创建serviceaccount K8s集群账号分为用户账号useraccount和Serviceaccount（是指pod想访问api-server要用到的用户账号密码等） apiVersion: v1 kind: ServiceAccount metadata: name: admin namespace: default 2.自定义pod连接api的认证用户 apiVersio...
自定义服务账户（Service Account）
IT老男孩
08-09 1721
本文永久链接: https://www.xtplayer.cn/kubernetes/custom-serviceaccount/Service account 主要是为了方便 Pod 中的进程调用 Kubernetes API 而设计的，为服务提供了一种方便的认证机制。但它不提供授权，需要配合 RBAC 来为 Service Account 鉴权。用户帐户与服务帐户Kubernetes 出于多种...
K8S用户管理体系介绍
singless的博客
08-17 1349
在k8s中，有两类用户，service account和user，我们可以通过创建role或clusterrole，再将账户和role或clusterrole进行绑定来给账号赋予权限，实现权限控制，两类账户的作用如下。server account：k8s的进程、pod申请授权时使用的账户。类似于nginx服务会有一个nginx用户。user：k8s的管理人员使用的账户，也就是我们使用的账户。
k8s里RBAC是什么意思
07-17
RBAC是Kubernetes中的一种访问控制机制，全为Role-Based Access Control，即基于角色的访问控制。RBAC用于定义和管理用户、ServiceAccount或其他身份对Kubernetes资源的问权限。 RBAC允许管理员根用户的职责和角色来授予不同级别的权限，以限制和管理对Kubernetes集群中的资源的操作。通过使用RBAC，可以实现精细的访问控制和权限分配。 在RBAC中，主要有以下几个核心概念： 1. Role：定义了一组权限规则，用于授权对特定命名空间中的资源进行操作。 2. ClusterRole：类似于Role，但是作用于整个集群而不是单个命名空间。 3. RoleBinding：将Role绑定到用户、ServiceAccount或其他身份上，从而为其授予相应的权限。 4. ClusterRoleBinding：将ClusterRole绑定到用户、ServiceAccount或其他身份上，赋予其集群级别的权限。 通过使用RBAC，管理员可以根据实际需求创建和配置不同的角色和绑定，确保每个用户或身份只能访问其所需的资源，并限制其对资源的操作。 RBAC是Kubernetes中重要的安全机制之一，可以帮助管理员实现对集群的访问控制和权限管理，提高集群的安全性和可管理性。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值