Skip to main content

Command Palette

Search for a command to run...

使用 JWT-SVID 做为访问 Valut 的凭据

Updated
5 min read

这次介绍的是在 SPIRE Server 和 Vault Server 之间建立 OIDC 联邦的方法。设置联邦之后,SPIRE 认证的工作负载就能使用 JWT-SVID 来通过 Vault Server 的认证。这样依赖,工作负载就无需使用 AppRole 或者用户名密码的方式来进行认证了。

这里解决的就是 0 号海龟问题:如何使用 SPIRE 作为 idP,让应用通过免认证 API 获取自己的身份,以此作为凭据来访问联邦中的 SP 服务

本文的操作将会涉及以下内容:

  • 部署 OIDC Discovery Provider Service

  • 创建一个 DNS A 记录,指向 OIDC Discovery document

  • 设置一个本地的 Vault Server,用于存储机密

  • 为 Vault 服务器设置一个 SPIRE Server OIDC Provider 作为认证方法

  • 使用 SPIRE 身份来访问机密数据

开始之前

本文内容需要一个公网可以访问的 Kubernetes 以及,并且要开放一个 Ingress 到公网。并且具有一个能够设置 A 记录的域名。另外因为需要暴露 Loadbalancer 类型的服务,因此最好使用公有云的托管 K8s 进行尝试;并且这里需要使用 Ingress,所以集群里如果没有 Ingress 控制器,还需要部署一个。

另外需要从 https://github.com/spiffe/spire-tutorials.git 克隆代码。

注意:目前(2023-01-16)代码中涉及的部分配置已经过期,请参考 https://github.com/spiffe/spire-tutorials/pull/107 的内容进行修复。

根据快速开始章节的指导,准备环境,大致过程如下:

进入代码的 spire-tutorials/k8s/quickstart 目录,执行操作。

首先是启动 SPIRE Server:

# 创建命名空间
$ kubectl apply -f spire-namespace.yaml
# 创建 SPIRE Server 所需的 ServiceAccount 及其授权
# 创建 Configmap 用于存储 Trust Bundle
$ kubectl apply \
    -f server-account.yaml \
    -f spire-bundle-configmap.yaml \
    -f server-cluster-role.yaml
# 创建 SPIRE Server Configmap
# 创建 SPIRE Server 的 StatefulSet 以及 Service 对象
$ kubectl apply \
    -f server-configmap.yaml \
    -f server-statefulset.yaml \
    -f server-service.yaml

接下来启动 SPIRE Agent:

# 给 Agent 创建 Service Account 并进行授权
$ kubectl apply \
    -f agent-account.yaml \
    -f agent-cluster-role.yaml
# 创建 Agent Configmap,并用 Daemonset 的形式启动 Agent
$ kubectl apply \
    -f agent-configmap.yaml \
    -f agent-daemonset.yaml

然后是注册工作负载:

# 创建 Node 注册项,使用 k8s_sat 作为 Selector
$ kubectl exec -n spire spire-server-0 -- \
    /opt/spire/bin/spire-server entry create \
    -spiffeID spiffe://example.org/ns/spire/sa/spire-agent \
    -selector k8s_sat:cluster:demo-cluster \
    -selector k8s_sat:agent_ns:spire \
    -selector k8s_sat:agent_sa:spire-agent \
    -node
# 创建工作负载注册项
$ kubectl exec -n spire spire-server-0 -- \
    /opt/spire/bin/spire-server entry create \
    -spiffeID spiffe://example.org/ns/default/sa/default \
    -parentID spiffe://example.org/ns/spire/sa/spire-agent \
    -selector k8s:ns:default \
    -selector k8s:sa:default

最后是启动工作负载容器:

# 启动应用
$ kubectl apply -f client-deployment.yaml
...

配置 SPIRE 组件

这个案例用到的文件保存在 k8s/oidc-vault/8s 目录之中,搜索其中的 TODO,根据本地情况进行修改,涉及内容如下:

  • MY_EMAIL_ADDRESS:涉及文件 oidc-dp-configmap.yaml。这里需要一个 EMail 地址,这个地址需要满足 Let's Encrypt CA 的要求,用于 OIDC 联邦证书的签署,使用过程中不会向这个邮箱发送邮件。

  • MY_DISCOVERY_DOMAIN:涉及文件包括 ingress.yamloidc-dp-configmap.yaml 以及 server-configmap.yaml。此处需要前面提到的域名,用于定位 OIDC Discovery Document。例如 oidc-discovery.example.org

  • MY_CLUSTER_NAME:替换为 SPIRE 所在集群的名称,例如 gke_dev-prj_name-central1-c_vault-oidc-tutorial。涉及文件 server-configmap.yaml

上述文件中使用了 example.org 作为信任域,无需修改。

为 OIDC Discovery Provider 提供 Configmap

进入目录 k8s/oidc-vault/k8s,执行下面的命令来更新 SPIRE Server(Quickstart 中已经启动了 Server,这里做一个替换,加入 OIDC Discovery 的服务):

$ kubectl apply \
    -f server-configmap.yaml \
    -f oidc-dp-configmap.yaml \
    -f server-statefulset.yaml
# 验证运行结果
$ kubectl get pods -n spire -l app=spire-server -o \
    jsonpath='{.items[*].spec.containers[*].name}{"\n"}'
spire-server spire-oidc

注意上面提到的 PR,这个 Statefulset 使用的是双容器 Pod,因为启动顺序不可控的问题,需要修改正确的 LivenessProbe 来在合适的时机对 OIDC 相关容器进行重启,才能成功启动 Pod。

为 OIDC Discovery IP 地址配置 DNS

这里需要使用上文提到的 DNS 记录。下面的步骤会使用这个域名为 Discovery Document 提供端点。Vault Server 会到这里进行查询,完成 Valut Server 和 SPIRE 之间的认证过程。

实际上还可以使用 JWKS 进行 Vault 的集成认证。这种方式就不需要 DNS 记录了。但是与此相对的,要求 Valut 部署在 Kubernetes 集群之中。相关内容可以参考 Vault 官方文档

获取服务 IP 地址

前面创建的 spire-oidc 服务是 Loadbalancer 类型的服务,因此这里需要获取它的 IP 地址:

$ kubectl get service -n spire spire-oidc

NAME           TYPE           CLUSTER-IP    EXTERNAL-IP    PORT(S)          AGE
spire-oidc     LoadBalancer   10.12.0.18    34.82.139.13   443:30198/TCP    108s

创建 DNS 记录

将域名映射到上述地址。然后用 nslookup 等工具校验域名的有效性。例如:

$ nslookup oidc-discovery.example.org
Server:        203.0.113.0
Address:          203.0.113.0#53

Non-authoritative answer:
Name:    oidc-discovery.example.org
Address: 93.184.216.34

可以使用在线工具 DNS Propagation Checker 来观察 DNS 记录的传播过程。

DNS 生效后,可以在浏览器中访问 https://MY_DISCOVERY_DOMAIN/.well-known/openid-configuration,顺利的话,会看到如下 JSON 格式的返回内容:

{
  "issuer": "https://oidc-discovery.example.org",
  "jwks_uri": "https://oidc-discovery.example.org/keys",
  "authorization_endpoint": "",
  "response_types_supported": [
    "id_token"
  ],
  "subject_types_supported": [],
  "id_token_signing_alg_values_supported": [
    "RS256",
    "ES256",
    "ES384"
  ]
}

安装和配置 Vault Server

DNS 设置和验证完成之后,开始配置 Vault 服务器。

在 MacOS 中可以使用 Homebrew 安装 Vault,其它操作系统可以参考官方安装文档

建议全新安装 Vault Server,复用已有服务可能会有配置冲突。

打开一个新的终端窗口,进入源码路径的 ./k8s/oidc-vault 目录。在 ./vault/config.jcl 中加入配置内容,如下配置表示 Vault 监听 127.0.0.1 的 8200 端口;使用文件作为存储后端;为了测试方便,我们关闭了 TLS,当然,绝不推荐在生产环境中这样使用:

listener "tcp" {
   address     = "127.0.0.1:8200",
   tls_disable = 1
}

storage "file" {
   path = "vault-storage"
}

用这个配置文件启动 Vault 服务:

$ vault server -config ./vault/config.hcl
...
==> Vault server started! Log data will stream in below:
...

初始化 Vault 并解封

设置 VAULT_ADDR 环境变量为 http://127.0.0.1:8200,然后进行初始化:

$ vault operator init
...
Unseal Key 1: VI0/4yK8H/tHC625aDYaf62+Jmo5qqlizn5bVmsbY0j0
Unseal Key 2: UINTf0oPzpiMIhOU3CNzFpo6Pkun36hGKPlcbQUkl1qT
Unseal Key 3: SYO0yTfCn5IkoQ5f/JzE98yQI8Nfiv51gjXZMamyjXn/
Unseal Key 4: 90vXLQJqba32VpBxYr4jB9gRVu6gRC/uWt812oF44zzP
Unseal Key 5: 2eBBVUC63DOPqNKn4WPoxci4VOfchA7tOr3LTqHtS5FC
Initial Root Token: s.PFuCtYgzjh6mRAfAVjfsGv3O
...

建议记录上面的内容(Key 和 Token),后面马上就要用到。

接下来解封 Vault,需要从上面记录的秘钥中选择任意三个进行解封:

$ vault operator unseal

Unseal Key (will be hidden): <PASTE ONE OF YOUR KEYS HERE>

Key                Value
---                -----
Seal Type          shamir
Initialized        true
Sealed             true # <- 代表是否解封
Total Shares       5
Threshold          3
Unseal Progress    1/3 # <- 解封进度
Unseal Nonce       e1bf3fa2-0058-5703-e2dc-a5c45c1b7f9a
Version            1.3.4
HA Enabled         false

返回信息中看到了 Sealed: false 代表解封成功。

启用机密引擎并保存一个测试条目

使用 CLI 通过跟用户进行访问,启用 kv 引擎,然后保存数据。

首先设置环境变量:

$ export VAULT_ADDR=http://127.0.0.1:8200
# 使用前面记录的 Token:
$ export VAULT_TOKEN="s.PFuCtYgzjh6mRAfAVjfsGv3O"

启用引擎并保存测试数据:

$ vault secrets enable -path=secret kv
$ vault kv put secret/my-super-secret test=123

设置 SPIRE 和 OIDC 的联邦关系

启用 Vault 的 JWT 认证:vault auth enable jwt

设置 OIDC 发现地址:

$ vault write auth/jwt/config \
oidc_discovery_url=https://oidc-discovery.example.org \
default_role=“dev”

设置一个 my-dev-policy 策略,它将会用在后面创建的dev 角色上。

进入源码目录的 ./k8s/oidc-vault 目录,在 vault-policy.hcl 中定义策略,该策略具有读取 /secret/my-super-secret 的权限:

path "secret/my-super-secret" {
   capabilities = ["read"]
}

然后在 Vault 中加载新建的策略:

$ vault policy write my-dev-policy ./vault/vault-policy.hcl
...

创建 dev 角色,绑定 JWT 的 subjectaudience,并配置 sub,声明这个角色会用于认证。有效期设置为 24 小时,这个 Token 会使用 my-dev-policy 策略:

$ vault write auth/jwt/role/dev \
    role_type=jwt user_claim=sub \
    bound_audiences=TESTING \
    bound_subject=spiffe://example.org/ns/default/sa/default token_ttl=24h \
    token_policies=my-dev-policy
...

获取 Vault 凭据

接下来我们来获取用于 Vault 的 Token。这里使用客户端工作负载通过 SPIRE 联邦来获取和进行认证。

首先获取客户端工作负载的 Pod 名称,例如 client-7c94755d97-mq8dl。接下来获取客户端的 SVID:

$ kubectl exec client-7c94755d97-mq8dl -- /opt/spire/bin/spire-agent api fetch jwt \
   -audience TESTING \
   -socketPath /run/spire/sockets/agent.sock

从响应消息中获取 JWT 信息。他应该位于相应信息的 SVID 附近(例如 token(spiffe://xxxxx))。是一个长字符串。

认证

创建一个 payload.json 文件,包含如下 JSON 内容,将上个步骤中获得的 Token 替换到文件里:

{"role": "dev","jwt": "<PASTE_YOUR_JWT_TOKEN_HERE>"}

用这个 Payload 进行认证:

$ curl --request POST \
    --data @/path/to/payload.json \
    http://localhost:8200/v1/auth/jwt/login

返回信息大概如下格式:

{
   "request_id": "78bc2546-8e3f-900e-ac32-ae590870ea67",
   "lease_id": "",
   "renewable": false,
   "lease_duration": 0,
   "data": null,
   "wrap_info": null,
   "warnings": null,
   "auth": {
      "client_token": "s.lQ3KIYjUnFwCJkUnOKKF8kxn", # <- 客户端 Token
      "accessor": "ZdVaNVQDcOL15FNSjyWogwiX",
      "policies": [
            "default",
            "my-dev-policy"  # <- 我们创建的策略
      ],
      "token_policies": [
            "default",
            "my-dev-policy"
      ],
      "metadata": {
            "role": "dev"
      },
      "lease_duration": 86400,
      "renewable": true,
      "entity_id": "5e467f7c-7270-6e2d-2929-e76b9d2b5b32",
      "token_type": "service",
      "orphan": true
   }
}

测试访问机密数据

接下来用客户端 Token 访问数据:

$ curl \
     -H "X-Vault-Token: <PASTE_YOUR_client_token_HERE>" \
     http://127.0.0.1:8200/v1/secret/my-super-secret

CURL 使用 client_token 作为凭据,访问 Vault 服务的 REST API。Vault API 会返回下面的 JSON 输出,其中包含我们写入的样本数据:

{
   "request_id": "1a10d3f7-e3b4-2c05-48c5-94a04f3758bc",
   "lease_id": "",
   "renewable": false,
   "lease_duration": 2764800,
   "data": {
      "test": "123" # 测试数据
   },
   "wrap_info": null,
   "warnings": null,
   "auth": null
}

More from this blog

龙虾恐慌:AIOps 又要改名了?

ChatGPT 开始,把 AI 拉近到普罗大众的面前,让无数人感受到 AI 的亲民魅力。而龙虾,则把大模型驱动的自动化能力,突然间变得水灵灵、活泼泼地走进千家万户。它不只是“风口上的猪”,而是风口本身。热度高到让 Mac mini 一度断货,不知道这在不在库克的预料之内。 每代人都有每代人的鸡蛋,春节期间,我就领了我的鸡蛋。翻出古老的 MacBook Air M1,充值各种大模型。当然了,这个工具

Mar 9, 20261 min read

再见 2025

我猜不少人以为这个号废了吧?并没有,只是今年变化有点大,一直有种抄起键盘,无从说起的感觉,所以一直偷懒到今天,2025 的最后一天。 今年是我的第四个本命年,去年末一期播客里,大内说本命年不是灾年,是变化年,有危也有机。可是讲真啊,只看到危,没看到机。 各种因缘际会,从鹅厂跳槽到前东家,已经接近四年,第一个合同期已经进入尾声。除了前两年还在云原生领域嗷嗷叫,后两年基本都是些鸡零狗碎的东西了,用老东家的术语说是——偏离主航道,可谓是前景暗淡了。 一旦确定要滚蛋,反倒心思轻松起来,每天骑着我的小红车...

Jan 5, 20261 min read

辅助编程?dora 说:我知道你很急可是请你别急

从 OpenGPT 把大模型的火烧旺了之后,这三年来,相信很多组织或摩拳擦掌、或躬身入局,希望借助聪明能干的大模型,或想偿还技术宅,或想降本增效,或想弯道超车。一时间,沉寂许久的 AIxx 又活过来了,LLM Ops、Vibe Coding、中医大模型、GPT 算命等等,全都老树发新芽,焕发了勃勃生机。那么视角拉回从业者最关注的饭碗相关的领域之一——AI 辅助开发,产生了什么触动,应该如何拥抱呢? DORA 的年度报告中给出了很有意思的结论——强者恒强。 执行摘要部分总结了几个有趣的点: 问题...

Oct 6, 20251 min read

[译]dora:ai 辅助软件开发状态报告

执行摘要 在 2025 年,科技领导者面临的核心问题已不再是“是否要采用 AI”,而是“如何实现其价值”。 DORA 的研究基于超过 100 小时的定性访谈和来自全球近 5,000 名技术专业人士的问卷调查。研究揭示了一个关键事实:AI 在软件开发中的主要角色是“放大器”。它会放大高效能组织的优势,也会凸显组织的缺陷。 关键结论:AI 是放大器 AI 投资的最大回报并非来自工具本身,而是来自组织底层系统的战略性建设: 高质量的内部平台 清晰的工作流 团队的协同能力 缺少这些基础,AI ...

Oct 2, 202514 min read

僭越了,有人在用 Rust 写 Kubernetes

一个新语言问世,最爱做的事情之一,就是重写存量软件了。 云原生喝酒 SIG 重点扶持项目——rk8s(https://github.com/rk8s-dev/rk8s) 也可以归在这个范畴里,只不过这个项目重写的东西比较大,是 Kubernetes。 从 2025 年 1 月第一个 Commit 开始,到现在有了 200 多次 Commit,十几万行代码。当然距离 Kubernetes 的几百万行代码还差得远——老马就是喜欢整这种大无畏项目。 另外该项目也是国内第一个脱离 Cargo 转向使用 ...

Sep 27, 20253 min read

【伪】架构师

342 posts