滁州市大滁城建设网站,wordpress 切换,一个页面多少钱,营销网站的策划方案怎么做K8s 的鉴权管理#xff08;二#xff09;#xff1a;基于属性 / 节点 / Webhook 的访问控制 1.基于属性的访问控制#xff08;ABAC 鉴权#xff09;2.基于节点的访问控制#xff08;node 鉴权#xff09;2.1 读取操作2.2 写入操作 3.基于 Webhook 的访问控制3.1 基于 We… K8s 的鉴权管理二基于属性 / 节点 / Webhook 的访问控制 1.基于属性的访问控制ABAC 鉴权2.基于节点的访问控制node 鉴权2.1 读取操作2.2 写入操作 3.基于 Webhook 的访问控制3.1 基于 Webhook 的访问控制的架构3.2 基于 Webhook 的访问控制的运行机制 1.基于属性的访问控制ABAC 鉴权
✨ 官方文档https://kubernetes.io/docs/reference/access-authn-authz/abac/ ❗ ABAC 鉴权功能从 Kubernetes 1.6 版本被弃用。 基于属性的访问控制Attribute-Based Access ControlABAC通过将属性组合在一起来定义用户可以访问的范围。其策略文件是一个具有多行 JSON 格式的文件该文件中的每一行都是一个策略即一个 JSON 对象。
下表列举了该 JSON 对象应具备的属性。
属性 属性中的字段 版本控制1️⃣ apiVersion字符串类型。该字段表示匹配 Kubernetes API 的哪些版本。该字段允许的值为 abac.authorization.kubernetes.io/v1beta1。2️⃣ kind字符串类型有效值为 Policy。spec1️⃣ user字符串类型。该字段的值可以是验证通过的用户名也可以是通过 --token-auth-file 指定的 Token 文件。2️⃣ group字符串类型。如果指定了该字段则它必须是经过身份验证的用户组。使用 system:authenticated 可以匹配所有经过身份验证的用户组使用 system:unauthenticated 可以匹配所有没有经过身份验证的用户组。资源匹配1️⃣ apiGroup字符串类型表示匹配一个 Kubernetes API 资源组。使用 * 则匹配所有 API 资源组。也可以具体指定某一个资源组例如 extensions。2️⃣ namespace字符串类型表示匹配某一个命名空间。使用 * 则匹配所命名空间。也可以具体指定某一个命名空间例如 kube-system。3️⃣ resource字符串类型表示匹配的资源类型。使用 * 将匹配所资源。也可以具体指定某一个或者某几个资源例如 pod、service。非资源匹配nonResourcePath字符串类型表示请求的路径。例如/version 或 /apis。该字段也可以使用通配符。例如使用 * 则匹配所有非资源请求使用 /dev/* 则匹配 /dev/ 的所有子路径。readonly布尔类型。当该字段被设置为 true 时资源匹配策略仅适用于 GET、LIST 和 WATCH 操作而非资源匹配策略仅适用于 GET 操作。
下面是使用 ABAC 鉴权时的几个 JSON 策略。
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}
}Bob 用户可以在命名空间 dev-demo 中访问 Pod。
{apiVersion: abac.authorization.kubernetes.io/v1beta1,kind: Policy,spec: {user: bob,namespace: dev-demo,resource: pods,readonly: true}
}在实际情况中通常会把一个 JSON 字符串放到一个 JSON 策略文件中来作为访问控制的策略文件。在配置完 JSON 策略文件后在重启 API Server 时需要指定该文件才能获取新的策略。 2.基于节点的访问控制node 鉴权
✨ 官方文档https://kubernetes.io/docs/reference/access-authn-authz/node/
基于节点的访问控制node 鉴权是专门针对 kubectl 发出的 API 请求的一种鉴权。 要启用基于节点的访问控制则需要在启动 API Server 时使用 --authorization-modeNode 参数。 对于 kubectl 执行的 API 请求Node 鉴权过程主要包括 读取操作 和 写入操作。
2.1 读取操作
当 kubectl 使用基于节点的方式操作 API 资源时允许对以下资源进行 读取操作
Pod、Service、Endpoint、NodeSecret、ConfigMap、PVC绑定到 kubelet 节点的与 Pod 相关的持久卷
2.2 写入操作
当 kubectl 使用基于节点的方式操作 API 资源时允许对以下的资源进行 写入操作
节点和节点状态启用 NodeRestriction 准入控制器以限制 kubelet 只能修改本节点的信息。Pod 和 Pod 状态启用 NodeRestriction 准入控制器以限制 kubelet 只能修改绑定到本节点的 Pod 信息。Event事件。 由于写入操作需要启用 NodeRestriction准入控制器因此在启动 API Server 时需要在 --enable-admission-plugins 中加入 NodeRestriction例如--enable-admission-plugins...,NodeRestriction,... 3.基于 Webhook 的访问控制
✨ 官方文档https://kubernetes.io/docs/reference/access-authn-authz/webhook/
基于 Webhook 的访问控制定义了 HTTP 的一个回调接口从而实现在某些特定事件发生时该接口的应用会向一个远端的授权服务器发送 HTTP POST 信息。因此在启用基于 Webhook 的访问控制后Kubernetes 会调用外部的服务来对用户访问的资源进行授权。 要启用基于 Webhook 的访问控制则需要在启动 API Server 时使用 --authorization-modewebhook 参数。 3.1 基于 Webhook 的访问控制的架构
基于 Webhook 的访问控制的架构如下图所示。
从架构来看基于 Webhook 的访问控制其实是一种基于 HTTP 协议的客户端与服务器Client-Server架构。由于 Kubernetes 的访问控制是围绕 API Server 进行的因此这里的 HTTP 客户端就是 API Server而 HTTP 服务器端就是远端的授权服务器。在配置 HTTP 客户端 API Server 时需要使用一个配置文件来指定远端的授权服务器的信息。
下面是 Kubernetes 官方提供的一个 HTTP 客户端配置示例。
# Kubernetes API version
apiVersion: v1
# kind of the API object
kind: Config
# clusters refers to the remote service.
clusters:- name: name-of-remote-authz-servicecluster:# CA for verifying the remote service.certificate-authority: /path/to/ca.pem# URL of remote service to query. Must use https. May not include parameters.server: https://authz.example.com/authorize# users refers to the API Servers webhook configuration.
users:- name: name-of-api-serveruser:client-certificate: /path/to/cert.pem # cert for the webhook plugin to useclient-key: /path/to/key.pem # key matching the cert# kubeconfig files require a context. Provide one for the API Server.
current-context: webhook
contexts:
- context:cluster: name-of-remote-authz-serviceuser: name-of-api-servername: webhook其中的 clusters 字段代表的是远端的授权服务器。 有了客户端的配置文件后在启动 API Server 时除要指定使用 Webhook 的鉴权方式即设置 --authorization-modewebhook 参数外还需要用 --authorization-webhook-config-file 参数来指定 HTTP 客户端 API Server 的配置文件。
3.2 基于 Webhook 的访问控制的运行机制
在 Kubernetes 配置好基于 Webhook 的访问控制后在进行鉴权时API Server 会自动向远端的授权服务器发送一个 HTTP POST 的报文在该请求中包含一个 JSON 格式的 SubjectAccessReview 对象用来描述当前执行的动作请求。
以下是对 Kubernetes 的资源对象请求进行鉴权的 HTTP POST 报文格式。该报文希望 jane 用户可以获取 Pod 的列表。
{apiVersion: authorization.k8s.io/v1beta1,kind: SubjectAccessReview,spec: {resourceAttributes: {namespace: kittensandponies,verb: get,group: unicorn.example.org,resource: pods},user: jane,group: [group1,group2]}
}可以看出SubjectAccessReview 对象中除包含被访问资源和请求的动作信息外还包含用户的信息。
如果要对 Kubernetes 的非资源对象的请求进行鉴权则报文格式如下
{apiVersion: authorization.k8s.io/v1beta1,kind: SubjectAccessReview,spec: {nonResourceAttributes: {path: /debug,verb: get},user: jane,group: [group1,group2]}
}远端的授权服务器在收到 HTTP POST 报文后如果鉴权成功则返回一个 SubjectAccessReview 对象并在对象中填充 status 字段来允许访问。例如
{apiVersion: authorization.k8s.io/v1beta1,kind: SubjectAccessReview,status: {allowed: true}
}在远端的授权服务器拒绝请求的 HTTP POST 报文时也是通过填充 status 字段来拒绝。例如
{apiVersion: authorization.k8s.io/v1beta1,kind: SubjectAccessReview,status: {allowed: false,reason: user does not have read access to the namespace}
}如果远端的授权服务器拒绝了 API Server 的请求同时也想拒绝其他授权者再次对该请求进鉴权则可以在 status 字段中增加一个 denied 参数。例如
{apiVersion: authorization.k8s.io/v1beta1,kind: SubjectAccessReview,status: {allowed: false,denied: true,reason: user does not have read access to the namespace}
}
