k8s_day07_02

静态密码方式认证k8s

kubeconfig

1、kubeconfig 配置文件：

​ 在 /etc/kubernetes/有conf 结尾的文件 ，那个就是kubeconfig 类型的配置文件。用于控制节点组件 和api交互时提供的身份验证。将用户名、认证信息等组织一起，便于认证到API Server上的认证信息文件；

[root@master01 ~]# ls /etc/kubernetes/*.conf
/etc/kubernetes/admin.conf  /etc/kubernetes/controller-manager.conf  /etc/kubernetes/kubelet.conf  /etc/kubernetes/scheduler.conf
[root@master01 ~]# 

kubeconfig 主要内容是 用户列表、集群列表信息， 程序调用时使用的context：当前准备什么用户管理哪个集群（用户和集群的映射关系）

支持一个文件中保存m个集群的n个认证信息；

2、kubeconfig 命令

客户端程序kuvbectl 可以通过默认路径（~/.kube/） 、–kubeconfig、 KUBECONFIG 环境变量加载自定义的kubeconfig 文件。

eg:

[root@master01 ~]# kubectl  options |grep cache
      --cache-dir='/root/.kube/cache': Default cache directory
      
[root@master01 ~]# kubectl  options |grep '\--kubeconfig'
      --kubeconfig='': Path to the kubeconfig file to use for CLI requests.

[root@master01 ~]#  kubectl get po/mypod  --kubeconfig=/etc/kubernetes/admin.conf
NAME    READY   STATUS    RESTARTS   AGE
mypod   1/1     Running   0          137m
[root@master01 ~]# 

[root@master01 ~]# export KUBECONFIG=/etc/kubernetes/admin.conf
[root@master01 ~]# kubectl get po/mypod 
NAME    READY   STATUS    RESTARTS   AGE
mypod   1/1     Running   0          139m

查看 kubeconfig 文件配置

不指定，默认显示的是家目录的

[root@master01 ~]# kubectl  config view
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://kubeapi.magedu.com: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
[root@master01 ~]# 

查看context

[root@master01 ~]# kubectl  config  get-contexts
CURRENT   NAME                          CLUSTER      AUTHINFO           NAMESPACE
*         kubernetes-admin@kubernetes   kubernetes   kubernetes-admin   
[root@master01 ~]# 

3、密码认证

静态密码文件：
password,user,uid,“group1,group2,group3”

修改apiserver.yaml

  - --basic-auth-file=/etc/authfiles/passwd.csv
 
   - mountPath: /etc/authfiles/
      name: authfiles
      readOnly: true


  - hostPath:
    path: /etc/authfiles/
    type: DirectoryOrCreate
    name: authfiles

[root@master01 ~]# cat /etc/authfiles/passwd.csv 
ilinux@Magedu,ilinux,1100,"kubeusers,kubeadmin"
ik8s@Magedu,ik8s,1200,"kubeusers"

/etc/kubernetes/manifests/kube-apiserver.yaml 修改后 kubelet 会自动扫描应用

[root@master01 ~]# kubectl exec kube-apiserver-master01 -it  -n kube-system  -- kube-apiserver --help|grep  basic
[root@master01 ~]# 

1.20 版本不支持. 所以。。.。

x509 认证

k8s 证书体系

使用openssl创建。 缺点 无法集中 方便 管理客户证书 可以通过Valut 系统管理

k8s 一共使用3套ca

1、apiserver 当作为服务端时使用的ca 就是 kubernetes-ca ， 是 k8s主ca签名的证书。

主ca 自签名证书

[root@master01 pki]# cd /etc/kubernetes/pki/
[root@master01 pki]# ls ca.*
ca.crt  ca.key

api 服务端ca

[root@master01 pki]# ls apiserver.*
apiserver.crt  apiserver.key

​ 在节点加入k8s 集群时，会创建向 k8s主ca的证书申请请求 。kubelet 使用的ca 是子ca. 使用kubeadm 时， 控制平面所使用的组件都是 子ca , kubeadm 会帮我们 自动创建

2、ecd 是另外一套自己的自签名CA 。api 作为客户端向etcd 访问时 ，api 会使用etcd 签名的证书子ca

[root@master01 pki]# ls apiserver-etcd-client.*
apiserver-etcd-client.crt  apiserver-etcd-client.key

api 做为客户端 请求访问 kubelet 节点查询pod 信息时使用的ca

[root@master01 pki]# ls apiserver-kubelet-client.*
apiserver-kubelet-client.crt  apiserver-kubelet-client.key

etcd 主 ca

[root@master01 pki]# ls etcd/ca*
etcd/ca.crt  etcd/ca.key

etcd 作为服务端时使用的ca

[root@master01 pki]# ls  etcd/server.*
etcd/server.crt  etcd/server.key

etcd 内部集群通信时使用的ca

[root@master01 pki]# ls  etcd/peer*
etcd/peer.crt  etcd/peer.key
[root@master01 pki]# 

3、对接外部时 ，使用的聚合器是另外一套ca

自定义证书认证

1、生成用户自定义的证书

使用k8s主ca 签名就行

[root@master01 pki]# pwd
/etc/kubernetes/pki
[root@master01 pki]# 
[root@master01 pki]# mkdir usercerts
[root@master01 pki]# cd usercerts/
[root@master01 usercerts]# (umask 077;openssl genrsa -out magedu.key 2048)
Generating RSA private key, 2048 bit long modulus
....................................................................................+++
............................+++
e is 65537 (0x10001)
[root@master01 usercerts]# 


[root@master01 usercerts]# openssl  req -new -key magedu.key -out magedu.csr -subj "/CN=magedu/O=kubeusers"
[root@master01 usercerts]# openssl x509 -req -days 3650 -CA /etc/kubernetes/pki/ca.crt  -CAkey /etc/kubernetes/pki/ca.key  -CAcreateserial -in magedu.csr -out magedu.crt
Signature ok
subject=/CN=magedu/O=kubeusers
Getting CA Private Key
[root@master01 usercerts]# ls
magedu.crt  magedu.csr  magedu.key
[root@master01 usercerts]# 

2、生成需要管理的cluster 信息 ，保存到kubeconfig 文件中

[root@master01 usercerts]# kubectl config set-cluster  kubernetes --server=https://kubeapi.magedu.com:6443 --embed-certs --certificate-authority=/etc/kubernetes/pki/ca.crt --kubeconfig=/tmp/mykubeconfig
Cluster "kubernetes" set.

3、生成需要管理的user 信息 ，保存到kubeconfig 文件中

[root@master01 usercerts]# kubectl  config set-credentials magedu --client-certificate=./magedu.crt --client-key=./magedu.key --embed-certs=true --kubeconfig=/tmp/mykubeconfig
User "magedu" set.
[root@master01 usercerts]# 

–embed-certs=true 会加密kubeconfig 的证书信息

[root@master01 usercerts]# kubectl   config view --kubeconfig=/tmp/mykubeconfig
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://kubeapi.magedu.com:6443
  name: kubernetes
contexts: null
current-context: ""
kind: Config
preferences: {}
users:
- name: magedu
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED

4、创建user 、cluster 的对应关系 context

[root@master01 usercerts]#  kubectl  config set-credentials magedu --client-certificate=./magedu.crt --client-key=./magedu.key --embed-certs=true --kubeconfig=/tmp/mykubeconfig
User "magedu" set.
[root@master01 usercerts]# kubectl   config  set-context 'magedu@kubernetes'  --user=magedu --cluster=kubernetes  --kubeconfig=/tmp/mykubeconfig
Context "magedu@kubernetes" created.
[root@master01 usercerts]# kubectl   config  use-context magedu@kubernetes --kubeconfig=/tmp/mykubeconfig
Switched to context "magedu@kubernetes".

验证结果

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://kubeapi.magedu.com:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: magedu
  name: magedu@kubernetes
current-context: magedu@kubernetes
kind: Config
preferences: {}
users:
- name: magedu
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
[root@master01 usercerts]# 

[root@master01 usercerts]# kubectl get nodes --kubeconfig=/tmp/mykubeconfig
Error from server (Forbidden): nodes is forbidden: User "magedu" cannot list resource "nodes" in API group "" at the cluster scope
[root@master01 usercerts]# 

出现这个原因是因为没有授权

5.1、kubeconfig 配置文件的合并

kubectl config 如果不用 --kubeconfig= 选项 ， 那么所的有的修改都会保存在默认的 家目录的那个kube文件中

例子： 对

没改之前， 因为配置文件中已经有了 集群kubernetes 列表项 ，主要创建新的context 列表项。修改现在使用的context 就行

[root@master01 usercerts]# kubectl   config  view

直接修改

[root@master01 usercerts]#  kubectl  config set-credentials magedu --client-certificate=./magedu.crt --client-key=./magedu.key --embed-certs=true 
User "magedu" set.
[root@master01 usercerts]# kubectl   config  set-context 'magedu@kubernetes' --user=magedu --cluster=kubernetes 
Context "magedu@kubernetes" created.
[root@master01 usercerts]#  kubectl   config  use-context magedu@kubernetes 
Switched to context "magedu@kubernetes".
[root@master01 usercerts]# 

验证

[root@master01 usercerts]#  kubectl   get ns
Error from server (Forbidden): namespaces is forbidden: User "magedu" cannot list resource "namespaces" in API group "" at the cluster scope
[root@master01 usercerts]# 

5.2、–context

为了方便 使用context ，可以直接在命令行指定

[root@master01 usercerts]#  kubectl   get ns
Error from server (Forbidden): namespaces is forbidden: User "magedu" cannot list resource "namespaces" in API group "" at the cluster scope
[root@master01 usercerts]# kubectl get ns --context= 
NAME              STATUS   AGE
default           Active   11d
dev               Active   7h43m
kube-node-lease   Active   11d
kube-public       Active   11d
kube-system       Active   11d
longhorn-system   Active   11d
[root@master01 usercerts]# 

5.3、kubeconfig 的删除命令

[root@master01 usercerts]#  kubectl   config   delete-context  magedu@kubernetes 
deleted context magedu@kubernetes from /root/.kube/config

[root@master01 usercerts]#  kubectl   config   delete-user  magedu
deleted user magedu from /root/.kube/config
[root@master01 usercerts]# 

5.4 “合并 和 斩平”

​ export 变量同时 指定多个文件。 这样的后果是合并前有相同的列表项的话， 合并也会有 会重复。 比如有多个相同的集群名。

[root@master01 usercerts]# export KUBECONFIG="$HOME/.kube/config:/tmp/mykubeconfig"
[root@master01 usercerts]# kubectl config view 
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://kubeapi.magedu.com:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: kubernetes-admin
  name: kubernetes-admin@kubernetes
- context:
    cluster: kubernetes
    user: magedu
  name: magedu@kubernetes

合并 斩平

[root@master01 usercerts]# kubectl  config view --merge --flatten > /tmp/newkubeconfig

RBAC授权控制

逻辑分类：

DAC(自主访问控制，默认不启用selinux 的情况下就是)、MAC( 强访问控制 如 selinux) 、RBAC、ABAC

k8s 支持的最好的2种 ：RBAC、ABAC

RBAC 注意： 默认情况下 只允许定义的 规则 当中用户角色访问，没定义统统拒绝

RBAC 权限

​ API Server 是 RESTful风格的http/https服务。 所以权限指的是基于 http 方法：GET, POST, PUT, DELETE, PATCH 的操作等等。 这些操作 在RBAC 当中 叫 Action 行为/动作

​ 所以 权限指的是 什么Action能施加到哪些资源对象（object）上； 比如 GET Pods 、DELETE Namespaces

k8s 权限控制：

k8s 中和权限相关的四个资源类型：

Role:

​ 角色，名称空间级别；

role 和cluster role 定义了动作发出者(role/cluster) 可以在 资源对象上的操作【verb】.

[root@master01 usercerts]# kubectl  get role/kube-proxy -n kube-system -oyaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  creationTimestamp: "2021-12-13T03:52:31Z"
  name: kube-proxy
  namespace: kube-system
  resourceVersion: "194"
  selfLink: /apis/rbac.authorization.k8s.io/v1/namespaces/kube-system/roles/kube-proxy
  uid: e1f858b7-4141-4d0e-b45a-dba60a59ec71
rules:
- apiGroups:
  - ""
  resourceNames:
  - kube-proxy
  resources:
  - configmaps
  verbs:
  - get
[root@master01 usercerts]# 

把 角色赋予权限，再把角色指派给人 (RoleBinding/ClusterRoleBinding)

ClusterRole：

​ 集群角色，全局级别；

RoleBinding:

​ “角色绑定”，指是将用户与角色关联起来，意味着，用户仅得到了特定名称空间下的Role的权限，作用范围也限于该名称空间；

ClusterRoleBinding：

​ 集群角色绑定，让用户扮演指定的集群角色；意味着，用户得到了是集群级别的权限，作用范围也是集群级别；

​ User --> Rolebindig --> ClusterRole：权限降级，ClusterRole，用户得到的权限仅是ClusterRole的权限在Rolebinding所属的名称空间上的一个子集；

能接受施加Verb的目标有三类：

​ resources：资源类型，该类型下的所有对象都是目标， pods；
​ resourceNames：特定的对象个体，pods/mypod；
​ nonResourceURLs：非资源型的URL，/status, 比如 pod/log (表示pod 中日志)

Verbs：

​ create、get、list、delete、patch、update

特殊绑定

Subject --> RoleBinding --> Roles
Subject --> ClusterRoleBinding --> ClusterRoles

这是2种正常 给用户 赋予角色的操作： 分别 是 用户被授权于 名称空间级别、集群级别的操作 。

通常来说 集群级别 就是全局级别 ，啥都能管。而名称空间级别 就是 只能管 特定名称空间下 特定一部分的动作，而不是所有。

所以也可以赋予 集群级别 在 特定名称空间下操作角色 。 也就是 在这个名称空间下，它具有所有权限 ，也就相当于 是这个名称空间下的管理员了 。

Subject --> RoleBinding --> ClusterRoles