码迷,mamicode.com
首页 > 其他好文 > 详细

k8s的安全机制RBAC,Service Account

时间:2020-09-23 23:17:13      阅读:31      评论:0      收藏:0      [点我收藏+]

标签:为我   支持   地址   原因   k8s   业务流   data   密码   pac   

kubernetes的安全框架

官方文档:https://kubernetes.io/zh/docs/reference/access-authn-authz/rbac/

认证,鉴权,准入控制(只做控制,不拒绝)

  • 访问K8S集群的资源需要过三关:传输安全、认证、鉴权、准入控制
  • 普通用户若要安全访问集群API Server,往往需要证书、Token或者用户名+密码;Pod访问,需要ServiceAccount
  • K8S安全控制框架主要由下面3个阶段进行控制,每一个阶段都支持插件方式,通过API Server配置来启用插件。
    1. Authentication
    2. Authorization
    3. Admission Control

技术图片

对客户端身份认证有三种:

  • HTTPS 证书认证:基于CA证书签名的数字证书认证(推荐)
  • HTTP Token认证:通过一个Token来识别用户(容易泄露token,不推荐)
  • HTTP Base认证:用户名+密码的方式认证 (不推荐)

使用RBAC鉴权

基于角色(Role)的访问控制(RBAC)是一种基于企业中用户的角色来调节控制对计算机或网络资源的访问方法。

允许通过kubernetes API动态配置策略

技术图片

  • 角色
    • Role:授权特定命名空间的访问权限
    • ClusterRole:授权所有命名空间的访问权限
  • 角色绑定
    • RoleBinding:将角色绑定到主体(即subject)
    • ClusterRoleBinding:将集群角色绑定到主体
  • 主体(subject)
    • User:用户
    • Group:用户组
    • ServiceAccount:服务账号

Role 和 ClusterRole

在 RBAC API 中,一个角色包含一组相关权限的规则。权限是纯粹累加的(不存在拒绝某操作的规则)。 角色可以用 Role 来定义到某个命名空间上, 或者用 ClusterRole 来定义到整个集群作用域。

RoleBinding 和 ClusterRoleBinding

角色绑定(RoleBinding)是将角色中定义的权限赋予一个或者一组用户。 它包含若干主体(用户,组和服务账户)的列表和对这些主体所获得的角色的引用。 可以使用 RoleBinding 在指定的命名空间中执行授权, 或者在集群范围的命名空间使用 ClusterRoleBinding 来执行授权。

比如我们对ljy这个用户进行授权default命令空间Pod读取权限。

  • 用k8s CA签发客户端证书
  • 生成kubeconfigwenjian
  • 创建RBAC权限策略

因为我是本地安装的,所以我的CA提前建好了,位置放在 /opt/kubernetes/ssl/
我的kubernetes是二进制安装的,地址在 /opt/kubernetes/ ,kubeadm安装的 记得修改关键位置

所以下边本地建CA的步骤我就省略了

[root@master1 rbac]# cat cfssl.sh 
wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64
wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64
wget https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64
chmod +x cfssl*
mv cfssl_linux-amd64 /usr/bin/cfssl
mv cfssljson_linux-amd64 /usr/bin/cfssljson
mv cfssl-certinfo_linux-amd64 /usr/bin/cfssl-certinfo
[root@master1 rbac]# bash cfssl.sh
[root@master1 rbac]# cat cert.sh 

cat > ca-config.json <<EOF
{
  "signing": {
    "default": {
      "expiry": "87600h"
    },
    "profiles": {
      "kubernetes": {
        "usages": [
            "signing",
            "key encipherment",
            "server auth",
            "client auth"
        ],
        "expiry": "87600h"
      }
    }
  }
}
EOF

cat > ljy-csr.json <<EOF
{
  "CN": "ljy",
  "hosts": [],
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "CN",
      "ST": "BeiJing",
      "L": "BeiJing",
      "O": "k8s",
      "OU": "System"
    }
  ]
}
EOF

cfssl gencert -ca=/opt/kubernetes/ssl/ca.pem -ca-key=/opt/kubernetes/ssl/ca-key.pem  -config=ca-config.json -profile=kubernetes ljy-csr.json | cfssljson -bare ljy

[root@master1 rbac]# bash cert.sh

然后目录下就会生成ljy.kubeconfig这个文件,这是我们的kubeconfig鉴权文件。

应用rbac.yml

[root@master1 rbac]# cat rbac.yaml 
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

---

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: ljy
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
[root@master1 rbac]# kubectl apply -f ljy.kubeconfig

[root@master1 rbac]# kubectl --kubeconfig=ljy.kubeconfig  get pods
NAME                                      READY   STATUS      RESTARTS   AGE
mypod                                     0/1     Completed   0          6d1h
nfs-client-provisioner-67765b4998-cfd75   1/1     Running     0          5d21h
nginx-deployment-9cdc9bd5c-pzzst          1/1     Running     3          9d
nginx-deployment1-898d6bdf6-d7tvn         1/1     Running     0          5d23h
nginx-deployment2-5cb9b67b-zp6cv          1/1     Running     0          5d21h
secret-env-pod                            0/1     Completed   0          6d2h
web-nginx-dep2-66ccfd7fb7-z2x84           1/1     Running     2          14d

而使用Service Account则和这个类似,只不过service account对应的是服务授权,比如kubernetes dashboard的token。

官方文档:https://kubernetes.io/zh/docs/reference/access-authn-authz/service-accounts-admin/

Kubernetes 区分用户账户和服务账户的概念主要基于以下原因:

用户账户是针对人而言的。 服务账户是针对运行在 pod 中的进程而言的。
用户账户是全局性的。 其名称在集群各 namespace 中都是全局唯一的,未来的用户资源不会做 namespace 隔离, 服务账户是 namespace 隔离的。
通常情况下,集群的用户账户可能会从企业数据库进行同步,其创建需要特殊权限,并且涉及到复杂的业务流程。 服务账户创建的目的是为了更轻量,允许集群用户为了具体的任务创建服务账户 ( 即权限最小化原则 )。
对人员和服务账户审计所考虑的因素可能不同。
针对复杂系统的配置可能包含系统组件相关的各种服务账户的定义。 因为服务账户可以定制化地创建,并且有 namespace 级别的名称,这种配置是很轻量的。

k8s的安全机制RBAC,Service Account

标签:为我   支持   地址   原因   k8s   业务流   data   密码   pac   

原文地址:https://blog.51cto.com/liujingyu/2535860

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有
迷上了代码!