k8s中kubelet接口的认证和授权

出于监控的目的,需要获取k8s中pod的CPU以及内存使用率等指标,经过了解发现需要调用kubelet的指标接口去获取相应信息。然而调接口时发现得认证和授权,下面说明一下kubelet接口认证授权的过程。
默认情况下,没有携带身份凭证的匿名请求会被认证为用户system:anonymous以及组system:unauthenticated。如果要拒绝将匿名请求认证为以上的用户与组,配置kubelet的如下启动参数,那么匿名请求就会认证失败

authentication:
  anonymous:
    enabled: false

kubelet的认证方法与apiserver相似,有client证书认证及token认证。
开启client认证和token认证需要做如下配置

authentication:
  webhook:
    enabled: true
  x509: 
    clientCAFile: /xxxx.crt

以上配置表示开启了token认证以及X509证书认证。如果两个都开启,只需要一个验证通过即可。
当采用证书认证的方式时,需要一个ca.crt来验证apiserver的证书,还需要携带一个client.crt来表明自已的身份。在实际中,客户端还需要携带client.key。举例如下,

curl https://localhost:10250/metrics --cacert /etc/kubernetes/pki/ca.crt --cert /etc/kubernetes/pki/apiserver-kubelet-client.crt --key /etc/kubernetes/pki/apiserver-kubelet-client.key 

除了认证之外,还需要进行授权。
kubelet的默认授权模式为AlwaysAllow,所有通过认证的请求(包括通过认证的匿名请求)有权限访问kubelet所有的API。这显然是不合理的,所以我们需要像apiserver那样对不同的请求赋予不同的权限。
kubelet通过如下的方法把授权委托给apiserver:
在apiserver中开启authorization.k8s.io/v1beta1这个API组
配置kubelet的启动参数

authorization:
  mode: Webhook

然后kubelet就会通过apiserver的SubjectAccessReviewAPI来决定是否给每一个请求授权。kubelet与apiserver的API不一样,当访问kubelet的API时,kubelet需要把这个API映射到apiserver的API,apiserver才知道该授予怎样的权限。kubelet与apiserver的资源映射如下。比如A用户访问kubelet的Get /healthz,那么会映射为apiserver的Get /api/v1//nodes//proxy,然后kubelet会通过apiserver的SubjectAccessReview判断A用户是否有权限访问apiserver对应的API

kubelet APIresourcesub-resource
/stats/*nodesstats
/metrics/*nodesmetrics
/logs/*nodeslogs
/spec/*nodesspec
all othersnodesproxy

下面以token认证授权为例。
首选需要创建一个sa

kubectl create sa kubelet-test

创建clusterrole

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: kubelet-test
rules:
- apiGroups:
  - ""
  resources:
  - nodes/metrics
  verbs:
  - get 

接着绑定权限

Kubectl create clusterrolebinding kubelet-test --clusterrole=kubelet-test --serviceaccount=default:kubelet-test

现在就可以获取认证授权的token了。

kubectl describe secret kubelet-test-xxxx

当客户端使用该认证方式来发起请求的时候,需在Header参数中添加以下字段

Authorization: Bearer <token>

测试如下:

curl https://localhost:10250/metrics "Authorization: Bearer XXXXXX" -k
  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Kubernetes (K8s) 提供了多种身份验证和授权机制,包括基于令牌、基于证书、基于 OpenID Connect 等。以下是 K8s认证授权机制: 1. 基于令牌的认证K8s 使用令牌进行用户身份验证。用户可以使用用户名和密码向 K8s 集群请求令牌,该令牌可用于后续请求的身份验证。 2. 基于证书的认证K8s 还支持使用证书进行身份验证。集群管理员可以在集群生成证书,然后将证书分发给用户,让其用于身份验证。这种方法更加安全,因为证书可以被撤销。 3. OpenID Connect 认证K8s 还支持 OpenID Connect,这是一种基于 OAuth 2.0 的身份验证协议。它使得用户可以使用 Google、GitHub 等身份提供者进行身份验证,并获取到一个令牌,用于后续请求的身份验证。 在授权方面,K8s 提供了以下授权机制: 1. 基于角色的访问控制 (RBAC):K8s 的 RBAC 允许管理员为不同的用户或用户组分配不同的角色。角色定义了用户或用户组可以访问的资源和操作。 2. 基于节点的访问控制 (NBAC):NBAC 允许管理员为不同的节点分配不同的角色。角色定义了节点可以访问的资源和操作。 3. 基于命名空间的访问控制 (NSAC):NSAC 允许管理员为不同的命名空间分配不同的角色。角色定义了命名空间可以访问的资源和操作。 4. 基于 Webhook 的授权:Webhook 允许管理员将授权决策交给外部服务来进行。这种方法比较灵活,因为管理员可以根据需要进行自定义授权
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值