美文网首页kubernetesk8s
Kubernetes访问控制之鉴权

Kubernetes访问控制之鉴权

作者: 宏势 | 来源:发表于2023-02-16 16:49 被阅读0次

    鉴权是确定请求方有哪些资源的权限,API Server目前支持RBAC鉴权Node鉴权ABAC鉴权 和 Webhook模式

    一、RBAC鉴权

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

    要启用 RBAC,在启动 API 服务器时将 --authorization-mode 参数设置为一个逗号分隔的列表并确保其中包含 RBAC

    API对象

    RBAC API 声明了四种 Kubernetes 对象:RoleClusterRoleRoleBindingClusterRoleBinding

    RBAC.png
    • Role 或 ClusterRole 中包含一组代表相关权限的规则。 这些权限是纯粹累加的(不存在拒绝某操作的规则)

    • Role 定义命名空间内权限,ClusterRole是定义跨命名空间的权限

      Role定义例子如下:

      kind: Role
      apiVersion: rbac.authorization.k8s.io/v1
      metadata:
        namespace: default      ##如果kind是ClusterRole,无须指定,代表集群级别
        name: pod-reader
      rules:
      - apiGroups: [""]             #"" indicates the core API group 具体参考kubectl api-resources
        resources: ["pods"]         # 资源names, 子资源例子:["pods/log"]
        verbs: ["get", "watch", "list"]  #允许动作
      

      如果是Role,代表能访问default空间下的所有Pod,如果是ClusterRolo代表能访问所有空间下的Pod

      -指定固定某个资源名称

      rules:
      - apiGroups: [""]
        # 在 HTTP 层面,用来访问 ConfigMap 资源的名称为 "configmaps"
        resources: ["configmaps"]
        resourceNames: ["my-configmap"]
        verbs: ["update", "get"]
      

      -指定非资源端点

      rules:
      - nonResourceURLs: ["/healthz", "/healthz/*"] # nonResourceURL 中的 '*' 是一个全局通配符
        verbs: ["get", "post"]
      
    • RoleBinding 将Role定义的权限授予用户/用户组/服务账号 (统称主体subject)

    • ClusterRoleBinding 只能将ClusterRole定义的权限授予用户/用户组/服务账号(统称主体subject)
      将pod-reader角色授予普通用户myuser

      kind: RoleBinding
      apiVersion: rbac.authorization.k8s.io/v1
      metadata:
        name: read-pods
        namespace: default
      subjects:
      - kind: User       #支持User,Group,ServiceAccount 三种类型
        name: myuser
        apiGroup: rbac.authorization.k8s.io
      roleRef:
         kind: Role
         name: pod-reader
         apiGroup: rbac.authorization.k8s.io
      

    一个 RoleBinding 也可以引用某 ClusterRole 并将该 ClusterRole 绑定到 RoleBinding 所在的名字空间

    聚合的ClusterRole

    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
      name: monitoring
    aggregationRule:
      clusterRoleSelectors:
      - matchLabels:
          rbac.example.com/aggregate-to-monitoring: "true"
    rules: [] # 控制面自动填充这里的规则
    
    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
      name: monitoring-endpoints
      labels:
        rbac.example.com/aggregate-to-monitoring: "true"
    # 当你创建 "monitoring-endpoints" ClusterRole 时,
    # 下面的规则会被添加到 "monitoring" ClusterRole 中
    rules:
    - apiGroups: [""]
      resources: ["services", "endpointslices", "pods"]
      verbs: ["get", "list", "watch"]
    

    相关核心内置对象

    所有system:前缀都是系统自带命名规则

    1.主体Subject

    名称 类型 说明
    default ServiceAccount 每个命名空间自带
    system:anonymous User 匿名用户
    system:serviceaccounts Group 任务名字空间的服务账号都属于这个组
    system:serviceaccounts:空间名字 Group 该名字空间下的服务账号都属于这个组
    system:authenticated Group 所有通过身份认证的用户都属于这个组
    system:unauthenticated Group 所有未通过身份认证的用户都属于这个组
    system:masters Group 超级管理员cluster-admin所属的组

    system:serviceaccount: (单数)是用于服务账户用户名的前缀;
    system:serviceaccounts: (复数)是用于服务账户组名的前缀。

    2.默认ClusterRole/ClusterRoleBinding

    • 默认 ClusterRole 和 ClusterRoleBinding 都有kubernetes.io/bootstrapping=rbac-defaults 标签
    • 自动协商:在每次启动时,API 服务器都会更新默认 ClusterRole 以添加缺失的各种权限, 并更新默认的 ClusterRoleBinding 以增加缺失的各类主体。禁止可设置注解rbac.authorization.kubernetes.io/autoupdate=false
    默认ClusterRole 对应默认ClusterRoleBinding 说明
    cluster-admin cluster-admin, 绑定system:master组 超级管理员角色
    admin 大多数对象进行读/写操作包括角色和角色绑定
    edit 大多数对象进行读/写操作角色
    view 只有访问权限角色
    system:discovery system:discovery,绑定组 system:authenticated 允许以只读方式访问 API 发现端点

    如果要禁用匿名的未经过身份验证的用户访问,请在 API 服务器配置中中添加 --anonymous-auth=false 的配置选项

    • 创建一个dev空间的管理员dev-admin
    kubectl create rolebinding dev-admin --clusterrole=cluster-admin --user=dev-admin -n dev
    

    二、Node鉴权

    节点鉴权是一种特殊用途的鉴权模式,专门对 kubelet 发出的 API 请求进行授权,通过--authorization-mode=Node 启动API服务器开启
    为了获得节点鉴权器的授权,kubelet 必须使用一个凭证以表示它在 system:nodes 组中,用户名为 system:node:<nodeName>

    三、ABAC鉴权

    基于属性的访问控制(Attribute-based access control - ABAC)定义了访问控制范例, 其中通过使用将属性组合在一起的策略来向用户授予访问权限

    • 指定策略文件 --authorization-policy-file=SOME_FILENAME

    文件内容格式JSON lines,例如:

    • Alice 可以对所有资源做任何事情
    {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "alice", "namespace": "*", "resource": "*", "apiGroup": "*"}}
    
    • kubelet 可以读取任何 pod
    {"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "kubelet", "namespace": "*", "resource": "pods", "readonly": true}}
    

    一般都是使用RBAC + Node鉴权

    相关文章

      网友评论

        本文标题:Kubernetes访问控制之鉴权

        本文链接:https://www.haomeiwen.com/subject/dtsukdtx.html