K8s 安全访问：ServiceAccount

最新推荐文章于 2024-10-09 09:30:59 发布
最新推荐文章于 2024-10-09 09:30:59 发布
阅读量1.4k 收藏 3
点赞数
分类专栏： k8s 文章标签： kubernetes k8s ServiceAccount 准入控制器 Token管理器
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/myle69/article/details/104869403
版权

欢迎访问博客原文
官方：Kubernetes API 访问控制
官方：K8s 认证模块
官方：管理 Service Accounts
官方：使用准入控制插件

本文介绍 ServiceAccount(服务账户，简称sa)的相关内容。

访问 K8s Api Server 需要授权，有几种角色需要访问 apiserver：

  • 运维用户：通过 kubectl 交互，api server 会绑定一个特定用户，一般是admin用户。
  • Pod 内容器进程：一般使用特定的 sa 访问，sa属于namespace级别。
  • 其他客户端：可通过REST API交互。

namespace 与默认 sa

每个namespace都会创建默认的sa，下面是例子：

$ kubectl create namespace demo
namespace/demo created

$ kubectl get sa -n demo
NAME      SECRETS   AGE
default   1         24s

kubectl get sa default -o yaml -n demo 查看 default sa，yaml 如下：

apiVersion: v1
kind: ServiceAccount
metadata:
  creationTimestamp: "2020-03-14T09:13:23Z"
  name: default
  namespace: demo
  resourceVersion: "28056513"
  selfLink: /api/v1/namespaces/demo/serviceaccounts/default
  uid: 9b6b3184-8f8a-4f6a-bd56-8954ac9e4e71
secrets:
- name: default-token-9vcx8

sa 的 secret 长什么样？

可以看出，sa 使用了 default-token-9vcx8 这个 Secret，下面是其yaml数据。

kubectl get secret default-token-9vcx8 -o yaml -n demo

该 secret 属性如下(token、ca.crt属性仅截取了部分)。

apiVersion: v1
# secret 的三个数据属性字段
data:
  ca.crt: LS0tLS1CRUdJTiBDR...
  namespace: ZGVtbw==
  token: ZXlKaGJHY2lPaUpTVXpJ...
kind: Secret
metadata:
  annotations:
    kubernetes.io/service-account.name: default
    kubernetes.io/service-account.uid: 9b6b3184-8f8a-4f6a-bd56-8954ac9e4e71
  creationTimestamp: "2020-03-14T09:13:23Z"
  name: default-token-9vcx8
  namespace: demo
  resourceVersion: "28056512"
  selfLink: /api/v1/namespaces/demo/secrets/default-token-9vcx8
  uid: 6c685b56-66ef-4439-8fd0-1c59092129ff
type: kubernetes.io/service-account-token

几个重要的属性如下：

  • type： kubernetes.io/service-account-token

  • token ：实际是JWT Token，采用 RS256 非对称算法。

  • ca.crt：证书，通过base64解密后可以看到证书内容。

data 中属性都是base64加密的，可通过 echo 内容 | base64 --decode 解密。

下面通过证书来解密JWT Token，这里采用 jwt.io Debugger 工具在线解密。

将base64解密后的ca.crt内容填入公钥文件位置，JWT Token放入左侧，PAYLOAD就是解密后的内容。

在这里插入图片描述

Pod 与 默认 sa

创建Pod时若未指定sa，将采用当前namespace 的 default sa。

下面创建一个nginx Pod。

kubectl create -n demo -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx-container
    image: nginx
EOF

再看看 Pod 的数据。

kubectl describe pod nginx -n demo

下面是数据：

Name:         nginx
Namespace:    demo
Containers:
  nginx-container:
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-9vcx8 (ro)
Conditions:
Volumes:
  default-token-9vcx8:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-9vcx8
    Optional:    false
  • default-token-9vcx8 是demo namespace下默认sa中的secret
  • 创建Pod时将该sa的secret自动作为volume挂载到了容器中
  • 挂载的目录下就是 default-token-9vcx8 包含的三个属性，即：JWT token、JWT 公钥、namespace，都已自动通过base64解密，下面是容器中挂载的三个文件：
$ ls -l /var/run/secrets/kubernetes.io/serviceaccount
total 0
lrwxrwxrwx 1 root root 13 Mar 14 09:47 ca.crt -> ..data/ca.crt
lrwxrwxrwx 1 root root 16 Mar 14 09:47 namespace -> ..data/namespace
lrwxrwxrwx 1 root root 12 Mar 14 09:47 token -> ..data/token

Pod 中 sa 自动处理机制(准入控制器)

Pod 未指定 sa 时，Admission Controller (准入控制器) 会自动进行处理，准入控制器属于 apiserver 的一部分，当 pod 被创建或更新时，它会同步地修改 pod。

该插件默认激活，当Pod创建or更新时，会执行如下策略：

  • 若 Pod 未设置 sa，自动将其 sa 设置为 default
  • 若 Pod 未设置 ImagePullSecrets，自动将 sa 中ImagePullSecrets 添加到Pod
  • 将 sa 的 secret 中用于API访问的token以 volume形式挂载到容器中

其中第二点非常重要，可以用于自动处理 Docker Registry 的安全凭证。

sa 中的 Secret 来自何方(Token管理器)？

sa 属于一种安全凭证，其中包含Secret，那Secret又是如何添加到sa中的？先演示效果。

下面创建一个sa.

kubectl create -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: demo-sa
EOF

kubectl get sa demo-sa -o yaml 拿到yaml如下：

apiVersion: v1
kind: ServiceAccount
metadata:
  creationTimestamp: "2020-03-14T12:30:19Z"
  name: demo-sa
  namespace: default
  resourceVersion: "28078771"
  selfLink: /api/v1/namespaces/default/serviceaccounts/demo-sa
  uid: 83b4c80f-ef7d-4ccc-83dc-b88ca3230bcf
secrets:
- name: demo-sa-token-qsz5d

Secret demo-sa-token-qsz5d 是自动创建的，kubernetes.io/service-account-token 类型。

各namespace 中 kubernetes.io/service-account-token 类型的 Secret 中的公钥都是一样的。

给sa创建secret是由 Token Manager(Token 管理器) 以异步的方式完成，处理策略如下：

  • sa 创建时，自动为其创建 secret 以支持API访问
  • sa 删除时，自动删除关联的 secret
  • 删除 sa 中的 secret 时，自动为其创建新的 secret

利用 sa 自动处理 ImagePullSecret

当Pod未指定 ImagePullSecrets时，会自动使用sa的secret，从而替Pod统一屏蔽掉拉取镜像的 Secret。

为sa添加 imagePullSecrets 即可，当然也可以动态变更namespace的 default sa，添加后后续创建的所有Pod就会自动添加 imagePullSecrets 策略。

kubectl create -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: demo-sa
imagePullSecrets:
- name: registry-tecent-secret
EOF

下面创建Pod演示，需指定 spec.serviceAccountName 为上面的 demo-sa，demo-sa 中的 registry-tecent-secret 用于拉取镜像。

kubectl create -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  serviceAccountName: demo-sa
  containers:
  - name: nginx-container
    image: nginx
EOF

查看Pod的yaml数据，仅保留sa相关内容后如下：

apiVersion: v1
kind: Pod
spec:
  containers:
  - image: nginx
    name: nginx-container
    # 使用了 demo-sa 中的 secret 并挂载到容器中
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: demo-sa-token-qcpns
      readOnly: true
  # Token Manager 自动将sa中secret设置到了Pod中    
  imagePullSecrets:
  - name: registry-tecent-secret
  serviceAccount: demo-sa
  serviceAccountName: demo-sa

欢迎关注公众号 [陈一乐]，一起学习，一起成长

cyjrun
关注
专栏目录
k8s之service account
fengcai_ke的博客
07-11 3635
k8s service account分析
《云原生安全攻防》-- K8s攻击案例：高权限Service Account接管集群
09-02 371
在本节课程中，我们将学习一个K8s攻击案例，高权限Service Account接管集群。如果攻击者获取到有效的凭证，就有可能通过凭证来接管整个K8s集群。在这个课程中，我们将学习以下内容：K8s的认证方式：介绍两种比较常见的身份认证方式，UserAccount和ServiceAccount。K8s身份认证攻击案例：深入分析具体的攻击细节，了解攻击者是如何获取凭证并利用凭证来接管集群的。首先，我们...
k8s之ServiceAccount
热门推荐
weixin_37337210的博客
01-17 1万+
导读 上一篇说了k8s的RBAC授权模式，今天就来简单看一下其中涉及到的ServiceAccount。 简介 k8s创建两套独立的账号系统，原因如下： （1）User账号给用户用，Service Account是给Pod里的进程使用的，面向的对象不同 （2）User账号是全局性的，Service Account则属于某个具体的Namespace （3）User账号是与后端的用户数据库同步的，创建一个新用户通常要走一套复杂的业务流程才能实现，Service Account的创建则需要极轻量级的实现
【k8s】pod和serviceaccount关系
m0_45406092的博客
08-15 1274
Pod 和 ServiceAccount 的联系体现在权限管理和安全控制上。通过 ServiceAccount，你可以控制 Pod 如何与 Kubernetes API 服务器交互，授予它们执行任务所需的最小权限，从而增强集群的安全性和管理性。
K8S ServiceAccount
summer_fish的专栏
08-07 2133
一、ServiceAccount通常被用于授权Pod与集群中的其他资源和服务进行通信，以及访问一些需要权限的操作。ServiceAccount为Pod提供了一个身份，使得Pod能够与Kubernetes API进行交互。Kubernetes API会根据ServiceAccount的身份进行授权判断。通过ServiceAccount，Kubernetes管理员可以对Pod进行权限控制，限制它们能够访问的资源和操作，从而增强集群的安全性。
k8s创建服务账号——Service Account
码农崛起
08-20 1万+
http://docs.kubernetes.org.cn/84.html Service Account（服务账号）：是指由Kubernetes API 管理的账号，用于为Pod 之中的服务进程在访问Kubernetes API时提供身份标识（ identity ） 。Service Account通常要绑定于特定的命名空间，它们由 API Server 创建，或者通过 API 调用于动创建 ，附带着一组存储为Secret的用于访问API Server的凭据。 User Accounts 与 Serv
k8s的认证和service account简述
weixin_30608131的博客
05-21 409
k8s的认证： 与API server通信的客户端大致有两类： 1.集群客户端工具（kubectl、kubeadm、kubelet等） 2.集群内pod. 任何客户端访问k8s时的过程： 1.认证：任何客户端访问k8s，首先需要通过k8s的认证；认证通过是说明所用账号只是k8s的合法用户； 2.授权：认证通过后，是否具有对k8s集群中资源的操作，需要k8s对其进行授权检查； 3.准入...
《云原生安全攻防》-- K8s攻击案例：从Pod容器逃逸到K8s权限提升
最新发布
10-09 716
在一个完整的K8s攻击链路里，攻击者往往会通过入侵容器应用拿到shell权限，作为起始攻击点，随后从容器中逃逸到宿主机，获取宿主机权限。接下来，攻击者会进一步攻击k8s集群的组件或窃取高权限凭证完成K8s权限提升。在本节课程中，我们将介绍一个完整K8s攻击链路的案例，其中包括了从web入侵到容器逃逸，再到K8s权限提升的过程。第一个思路：攻击K8s集群的组件，通过利用这些组件的漏洞或不安全配置来获取对集群的控制权。2、案例解析：构建演示完整K8s攻击链路的攻击环境，深入分析具体的攻击细节。
k8s-ddns:为CoreDNS部署Kubernetes ExternalDNS
05-09
在Kubernetes（简称k8s）环境中，DNS解析是服务发现的关键部分，它使得应用能够通过服务名相互访问。CoreDNS作为Kubernetes的官方DNS服务器，负责为集群内的服务提供DNS解析服务。然而，对于集群外部的访问，比如从...
kubernetes10——访问控制（serviceaccount、useraccount、RBAC）
qwejiaji的博客
08-05 924
目录一、访问控制二、ServiceAccount三、UserAccount四、RBAC基于角色访问控制授权五、服务账户的自动化 一、访问控制 流程：认证、授权和准入控制 Authentication（认证） 认证方式现共有8种，可以启用一种或多种认证方式，只要有一种认证方式通过，就不再进行其它方式的认证。通常启用X509 Client Certs和Service Accout Tokens两种认证方式。 Authorization（授权） 必须经过认证阶段，才到授权请求，根据所有授权策略匹配请求资源属性
K8s中Service Account和RBAC
l1727377的博客
12-16 2870
①.ServiceAccount（服务账户）是Kubernetes集群中的一种资源对象，用于为Pod或其他资源提供身份验证和授权，以便它们能够与Kubernetes API进行交互。②.ServiceAccount是Kubernetes中用于管理Pod身份验证和授权的重要资源，它使得Pod能够在集群中具有独立的身份，从而实现更精细的权限控制和安全策略。③. Service Account它并不是给kubernetes集群的用户使用的，而是给pod里面的进程使用的，它为pod提供必要的身份认证。
K8S学习之serviceacount~RBAC授权
weixin_60092693的博客
01-25 1502
第一部分、认证 kubernetes上的账号 kubectl explain pods.spec可以看到有一个字段serviceAccountName（服务账号名称），这个就是我们pod连接apiserver时使用的账号，整个kubernetes集群中的账号有两类，ServiceAccount（服务账号），User account（用户账号） User account：实实在在现实中的人，人可以登陆的账号，客户端想要对apiserver发起请求，apiserver要识别这个客户端是否有请求的权限，那么不同的
K8S学习指南(36)-k8s权限管理对象ServiceAcount
俞兆鹏的博客
12-24 1234
通过本文，我们深入了解了Kubernetes中权限管理对象ServiceAccount的基本概念、使用方法，并通过详细的示例演示了如何创建ServiceAccount，并将其与Pod关联，以实现身份验证。在示例中，我们将创建一个ServiceAccount，并将其关联到一个简单的Pod，演示Pod如何使用ServiceAccount提供的令牌进行身份验证。上述步骤演示了如何创建ServiceAccount，并将其与Pod关联，以便在Pod中获取ServiceAccount提供的令牌进行身份验证。
K8s安全实践：使用ServiceAccount为应用程序授权
zgt_certificate的博客
06-18 476
当default SA创建时，会自动创建一个default-token-xxx的secret，并自动关联到SA。当创建namespace时，会自动创建一个名为default的SA，这个SA没有绑定任何权限。无需单独为某个用户创建权限，统一为这个组名进行授权，所有的用户都可以以组的身份访问资源。测试：只要O字段都是dev，这些用户持有的kubeconfig文件都拥有相同的权限。Kubernetes的默认授权策略，动态配置策略（修改即时生效）。通过RBAC可以实现对不同用户或服务账号的精细化权限控制。
k8s、ServiceAccount权限详解、RBAC 详解(基于角色的访问控制)，常用操作指令
mingqing的博客
11-29 4964
文章目录Service Account应用示例RBAC 详解(基于角色的访问控制)创建一个角色（role）---权限实验二常用操作指令 Service Account应用示例 概念图权限关系 我自己的理解就是，Service Account就是pod的权限 1、创建serviceaccount [root@kub-k8s-master ~]# kubectl create serviceaccount mysa serviceaccount/mysa created 2、查看mysa [root@kub
Kubernetes_认证授权_ServiceAccount_服务账号全解析
毛毛的专栏
10-23 2153
梳理出ServiceAccount服务账号一条线
k8s学习笔记-认证(Serviceaccount)
weixin_30274627的博客
05-09 647
可以使用kubectl、客户端库方式对REST API的访问，Kubernetes的普通账户和Service帐户都可以实现授权访问API。API的请求会经过多个阶段的访问控制才会被接受处理， 其中包含认证、授权以及准入控制（Admission Control）等。如下图所示： 需要注意：认证授权过程只存在HTTPS形式的API中。也就是说，如果客户端使用HTTP连接到kube-apiser...
详解 ServiceAccount -- k8s的服务账号是如何工作的？
千里之行
12-17 8216
Kubernetes 的 Service Account 是如何工作的
Kubernetes—Serviceaccount
屈帅波的技术博客
11-27 577
1.创建serviceaccount K8s集群账号分为用户账号useraccount和Serviceaccount（是指pod想访问api-server要用到的用户账号密码等） apiVersion: v1 kind: ServiceAccount metadata: name: admin namespace: default 2.自定义pod连接api的认证用户 apiVersio...
k8s serviceaccount
03-16
K8s ServiceAccount是Kubernetes中的一种对象，用于授权Pod或其他Kubernetes对象访问Kubernetes API。它是一种自动化的身份验证机制，可以为Pod提供访问Kubernetes API的令牌。通过使用ServiceAccount，可以更好地...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值