SPIFFE | 伪架构师

在 SPIRE 中用 SSH 证实节点身份

Sat, 17 Dec 2022 20:16:36 +0800

前面关于 SPIRE 的内容中，介绍了使用 JOIN Token 证实节点身份的方法。这种方法比较简易，但是完全依赖 SPIRE Server/Agent 的“内循环”，并不利于外部管理，同时每次节点更新，都要照本宣科的重来一遍。对于动态集群来说，这种方式并不理想，SPIRE 包含了面向 OpenStack、几大公有云以及 TPM 等的花钱证实节点身份的方案；除了这些之外，还有个经济型的证实方法——使用 SSH。

我们一般使用的免密登录 SSH 方案通常是点对点的，总结来说就是服务器和客户端各自有各自的公私钥，互相进行信任操作：

SSHD 会自动生成服务器端的公私钥
客户端通常使用 ssh-keygen 命令生成自己的公私钥
客户端将服务器端的证书脚印加到自己的 know_hosts 文件里面，代表信任该地址和证书的组合
服务器将客户端的公钥加到服务侧特定用户的 authorized_keys 文件之中，代表认可以该密钥作为特定用户的身份证明。

不难看出，这个过程实际上是跟前面的 JOIN Token 方式是对等的，并不会提升节点证实过程的可管理性。因此 SPIRE 的 SSH 插件要求使用基于 CA 的 SSH 方法。

用 CA 进行 SSH 认证

这种方式比上面的点对点认证方式稍微复杂一些。主要区别在于：

主机身份和用户身份都用 CA 进行签署
同样地，主机和用户身份的互信，也是通过对 CA 的信任完成

大概要完成几个工作：

创建节点 CA 证书，SSH 客户端信任该 CA 证书
用节点 CA 签发主机证书，并将服务端证书记录在 SSHD 的配置文件中。
创建客户端 CA 证书，SSH 服务端信任该 CA 证书
使用客户端 CA 签发用户证书，以此作为登录凭据。

例如 ChatGPT 告诉我的步骤是这样的：

几个关键的命令：

生成并配置 HostKey

下面的命令可以用于 SSHD 初始化，利用 CA 生成 HostKey：

ssh-keygen -s /etc/ssh/ca \
     -I "$(hostname --fqdn) host key" \
     -n "$(hostname),$(hostname --fqdn),$(hostname -I|tr ' ' ',')" \
     -V -5m:+3650d \
     -h \
     /etc/ssh/ssh_host_rsa_key.pub \
     /etc/ssh/ssh_host_dsa_key.pub \
     /etc/ssh/ssh_host_ecdsa_key.pub

查看一下生成的证书内容：

$ ssh-keygen -L -f ssh_host_rsa_key-cert.pub
ssh_host_rsa_key-cert.pub:
        Type: ssh-rsa-cert-v01@openssh.com host certificate
        Public key: RSA-CERT SHA256:[...]
        Signing CA: RSA SHA256:[...] (using rsa-sha2-512)
        Key ID: "ssh"
        Serial: 0
        Valid: from 2022-12-16T08:12:02 to 2032-12-13T08:17:02
        Principals:
                ssh
                ssh
                10.211.55.9
                fdb2:2c26:f4e4:0:21c:42ff:fe2a:18c4
        Critical Options: (none)
        Extensions: (none)

配置 HostKey

生成主机凭据之后，将证书和密钥信息加入 /etc/ssh/sshd_config：

HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key
HostCertificate /etc/ssh/ssh_host_ecdsa_key-cert.pub
HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub
HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub

让客户端信任主机 CA

和前面提到的 FingerPrint 方式类似，把 CA 证书公钥加入到客户端的 ~/.ssh/know_hosts 之中，例如：

@cert-authority * ssh-rsa ...AAAAB3NzaC1yc2EAAAADAQABAAABgQCb... someone@ssh

生成客户端证书

和前面生成主机身份证书的情况类似，这次去掉了 -h 参数：

ssh-keygen -s /etc/ssh/ca \
    -I "$(whoami)@$(hostname --fqdn) user key" \
    -n "$(whoami)" \
    -V -5m:+3650d \
    ~/.ssh/id_rsa.pub

服务端信任客户端证书 CA

同样在 /etc/ssh/sshd_config 配置中加入 TrustedUserCAKeys，具体取值为用户 CA 的公钥文件名。

完成这些内容之后，如果使用新的身份证书登录成功，则代表前置任务完成。否则可以参考以下材料：

SPIRE 配置

前面的 SSH 配置只是个铺垫。SPIRE 使用 SSHPOP 实现了 Server 和 Agent 侧的节点证实插件，两个插件需要协同工作，官网的说明非常简明扼要：

稍稍延展说明一下需要注意的要点：

SPIRE Agent 所在的节点实际上是作为 SSH 的服务端
SPIRE Agent 联系 SPIRE Server 之后，SPIRE Server 要通过 SSH 来访问 SSH 服务端来确认身份。

因此上面语焉不详的配置就比较清楚了：

SPIRE Server 的 cert_authorities 需要的是客户端证书内容，例如 ["ssh-rsa XXXX46IvQ+bDEXYvf8pM= someone@ssh"]
SPIRE Server 的 cert_authorities_path 指向节点 CA 公钥，例如 XXXX/ca.pub
SPIRE Agent 的 host_cert_path 指向主机证书文件，例如 XXXX_key-cert.pub
SPIRE Agent 的 host_key_path 指向密钥文件，例如 XXXX_key

配置完成之后，启动 SPIRE Server，获取并把 Trust Bundle 传递给 SPIRE Agent，启动 SPIRE Agent，可以看到生成了形如 "spiffe://spiffe.dom/spire/agent/sshpop/XXXX 的 SVID，说明这个证实过程已经成功完成。

后记

本以为这是个顺便完成的东西，结果从来没想过 SSH 还有个 CA 这样的玩意，卡了好些时间，轻敌了。

另，值此辞旧迎新之际，祝大家身体健康、事业稳定、学习进步、物资充足——最重要运气爆棚吧：）

用 SPIRE 为 Pod 提供身份

Thu, 24 Nov 2022 21:55:45 +0800

开始之前

SPIFFE 是一个认证框架，能为多种节点和工作负载类型提供证实能力，解决“我是我”的问题，前面文章演示过用 SPIRE 给类 Unix 进程提供身份的方法，今天这篇就试试给 Pod 提供身份。

这次实验会在前面的基础之上，在 Kubernetes 集群之外运行独立的 SPIRE Server，在集群中用 Pod 的形式运行 SPIRE Agent 作为节点，最后在其它 Pod 中访问 SPIRE Agent，获取 SVID。本文所涉及的对象关系如下图所示：

开始之前，需要做一些准备：

有一个 Kubernetes 集群，Kind 或者 Minikube 也都是可以完成测试的。
SPIRE 1.5.x 的二进制文件，可以从 https://spiffe.io/downloads/ 下载
构建镜像所需的基础镜像和 Podman/Docker 等工具。

Kubernetes 相关插件

这里要用到 SPIRE 的三个插件：

Kubernetes Node Attestor：用于证实 Node 身份，需要分别在 Server 和 Agent 两侧进行配置。目前可以选择 k8s_sat 或者 k8s_psat 两种插件，两侧的插件选择应保持一致，分别用于 ServiceAccount Token 和新版本 Kubernetes 中新增的 Projected ServiceAccount Token，本文选择的是 k8s_sat。

Projected Token 具有更好的安全性，延伸阅读：https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/）

Kubernetes Bundle：Trust Bundle 是数字证书的集合，在 Kubernetes 中往往需要使用 Configmap 来存储和共享，所以一个直接的想法就是通过 spire-server bundle show 命令来获取证书集合，并生成 Configmap。但是这个插件可以方便地通过 Kubernetes API 来自动维护证书集合到 Configmap 的转换过程，并自动完成轮转工作。

Kubernetes Workload Attestor：用于证实 Workload 身份，只需要在 Agent 中配置即可。

配置和启动 SPIRE Server

简单粗暴上配置：

server {
...
    }
}

plugins {
    DataStore "sql" {
...
    }

KeyManager "disk" {
...
}

    Notifier "k8sbundle" {
        plugin_data {
            kube_config_file_path = "/home/dustise/.kube/config"
        }
    }

    NodeAttestor "k8s_sat" {
        plugin_data {
            clusters = {
                "kindcluster" = {
                    service_account_allow_list = ["spire:spire-agent"]
                    use_token_review_api_validation = true

上面的 SPIRE Server 配置中，省略了通用部分，具体内容可以参考前面一篇文章，重点看一下两节 Kubernetes 相关配置。

k8sbundle 的作用就是把 Trust Bundle 内容保存到 Configmap 里面，因此是需要和 API Server 打交道的，这里给他直接配置了一个 KubeConfig 文件，访问方式还有其他的配置内容，可以参考官方文档。要注意的是，这里使用的 KubeConfig 文件所包含的账号是 Cluster Admin 权限，如果使用其他的账号，需要具备对 Configmap 进行 create 和 patch 操作的授权。

k8s_sat 一节中，clusters 字段是一个 Map，其中可以对接多个 Kubernetes 集群，这里我们填充了三个字段：

service_account_allow_list：允许 Agent 注册时使用的 Service Account。
use_token_review_api_validation：使用 TokenReview API 对 Serivce Account Token 进行验证，除此之外，还可以使用证书进行认证。
kube_config_file：和 API Server 进行沟通的凭据。

和 Bundle 类似，这里同样需要具备一定的权限来完成 SPIRE Server 的工作，

Configmap 的 patch、get、list
tokenreviews 的 create

创建好配置文件之后，可以先在目标集群中创建 spire 命名空间。使用 spire-server -config=[config file path] 命令启动服务器。稍后会在集群中看到新建的 Configmap。

更多配置信息可以参考官方文档

Server 启动成功后，可以提前为工作负载创建 Node 和 Entry：

spire-server entry create -socketPath=socks/spire-server.sock \
    -spiffeID spiffe://spiffe.dom/clusters/kindcluster \
    -selector k8s_sat:cluster:kindcluster -node

spire-server entry create -socketPath=socks/spire-server.sock \
    -spiffeID spiffe://spiffe.dom/ns/default/sa/default \
    -parentID spiffe://spiffe.dom/ns/spire/sa/spire-agent \
    -selector k8s:ns:default \
    -selector k8s🈂️default

首先用 k8s_sat:cluster:kindcluster 创建了一个在 spiffe.dom 中的 Node 条目，它的 SPIFFE ID 是 spiffe://spiffe.dom/clusters/kindcluster；

接下来以 Node 条目为上级，使用 k8s:ns:default + k8s🈂️default 的 Selector，创建一个 SPIFFE ID spiffe://spiffe.dom/ns/default/sa/default，代表在 default 命名空间中用 default Service Account 身份运行的 Pod。

创建 Agent

在运行 Agent 之前，首先要制作一个镜像，这里偷懒的使用现成二进制进行构建：

FROM busybox:1.35.0-glibc
RUN mkdir -p /spire/bin
COPY spire-agent /spire/bin
CMD ["/spire/bin/spire-agent", "-config=/spire/conf/k8s-agent.conf"]

这里要创建一个 Agent 的工作负载，为了让 Agent 能够通过进程号查询工作负载的 Pod 信息，并对工作负载提供 Workload API，需要满足几个条件：

Agent 需要有授权访问 Kubernetes 的特定资源
共享 Socket 文件，让 Workload 可以访问 Agent 提供的 Workload API
能够识别调用 Workload API 的进程的 Pod 信息，从而生成 Selector

综合以上考虑，我们需要设计这样的 Workload：

用主机卷的方式在每个节点上暴露 Socket
能够访问 Trust Bundle 所在的 Configmap
Agent 和 Workload 共享 IPC 空间，便于通过进程号识别身份
Agent 所使用的 Service Account 需要具备和 API Server/Kubelet 通信查询信息的能力。

因此产生如下的 YAML 片段：

    spec:
      hostPID: true
      hostNetwork: true
      serviceAccountName: spire-agent
...
      containers:
        - name: spire-agent
          image: gcr.io/spiffe-io/spire-agent:1.5.0
          args: ["-config", "/run/spire/config/agent.conf"]
          volumeMounts:
            - name: spire-config
              mountPath: /run/spire/config
              readOnly: true
            - name: spire-bundle
              mountPath: /run/spire/bundle
            - name: spire-agent-socket
              mountPath: /run/spire/sockets
              readOnly: false        
      volumes:
        - name: spire-config
          configMap:
            name: spire-agent
        - name: spire-bundle
          configMap:
            name: spire-bundle
        - name: spire-agent-socket
          hostPath:
            path: /run/spire/sockets
            type: DirectoryOrCreate
...

这段 YAML 有几个要点：

使用了符合 SPIRE Server 配置中要求的 ServiceAccount
HostPID 共享主机 PID 空间
HostNetwork 共享主机网络空间
加载 Trust Bundle 所在的 Configmap
加载一个主机卷用于输出 Socket 文件
用一个 Configmap 保存配置文件并加载

Agent 的配置文件如下：

agent {
  data_dir = "/run/spire"
  log_level = "DEBUG"
  server_address = "10.211.55.5"
  server_port = "8081"
  socket_path = "/run/spire/sockets/agent.sock"
  trust_bundle_path = "/run/spire/bundle/bundle.crt"
  trust_domain = "spiffe.dom"
}

plugins {
  NodeAttestor "k8s_sat" {
    plugin_data {
      cluster = "kindcluster"
    }
  }

  KeyManager "memory" {
...
  }

  WorkloadAttestor "k8s" {
    plugin_data {
      skip_kubelet_verification = true
    }
  }
}

Agent 配置相对来说稍显复杂：

server_address 和 server_pod，用于访问前面启动的 SPIRE SERVER
trust_bundle_path 引用 Configmap 的加载路径即可
trust_domain 需要保持和 SPIRE Server 定义一致
k8s_sat 的 cluster 字段中，集群名称需要和 SPIRE Server 的 Map 中的定义匹配
skip_kubelet_verification：跳过对 Kubelet 证书的检查

Agent 使用的 Service Account 也需要进行 RBAC 授权，需要能够对 pod、node 以及 node/proxy 进行 get 操作。

先后把配置 Configmap、RBAC 以及 Daemonset 等资源提交之后，会看到 Agent Pod 启动。

启动客户端

任意启动一个客户端程序，为模仿接入 Workload API 的实现，其中还是需要使用 SPIRE Agent 的二进制。客户端应该使用 Agent 的 Socket 访问 Wokrload API，同时为了表明身份，同样需要用 HostPID 供 Agent 识别，因此运行如下工作负载：

...
      hostPID: true
      hostNetwork: true
...
      containers:
        - name: client
          image: gcr.io/spiffe-io/spire-agent:1.2.3
          command: ["sleep"]
          args: ["1000000000"]
          volumeMounts:
            - name: spire-agent-socket
              mountPath: /run/spire/sockets
              readOnly: true
      volumes:
        - name: spire-agent-socket
          hostPath:
            path: /run/spire/sockets
            type: Directory

Pod 在 default 命名空间启动之后，进入 Shell 使用 spire-agent api fetch 命令，就能成功的获取 SVID 了：

$ bin/spire-agent api  fetch -socketPath=/run/spire/sockets/agent.sock
Received 1 svid after 83.772792ms

SPIFFE ID:              spiffe://spiffe.dom/shutup
SVID Valid After:       2022-11-24 17:02:03 +0000 UTC
SVID Valid Until:       2022-11-24 17:04:13 +0000 UTC
CA #1 Valid After:      2022-11-23 14:57:51 +0000 UTC

To be continued

现在我们就用一个非常笨拙的方法，把 Kubernetes 的工作负载识别能力接入到了 SPIRE Server 里面了。事实上接入 Kubernetes 还有别的部署和使用方式，例如使用 CRD、在集群内运行 SPIRE Server、使用 Envoy 等接入 Workload API 等。官网文档中对这些案例都有较为详细的指导。

结合前面对于 Ghostunel 等的介绍，不难看出，打通虚拟机和 Kubernetes 工作负载身份是可行的，而根据联邦一文的描述，这个体系还可以和 OIDC 等进行互通，进一步扩大 SPIFFE SVID 的版图。

用 Ghostunnel 和 SPIRE 为 NGINX 提供 SPIFFE 认证

Sat, 22 Oct 2022 21:55:16 +0800

之前对 SPIFFE 和 SPIRE 进行了一个相对全面/啰嗦的介绍，这一篇就反过来，用一个简单的例子来展示 SPIRE 的基本用法，本文中会以 NGINX 作为服务生产方，使用 Ghostunnel 当做 NGINX 的反向代理，把原有的 HTTP 通信升级为支持定期正顺轮转的双向 TLS 认证协议，并且用 CURL 使用客户端证书来通过 Ghostunnel 安全地访问背后的 NGINX。这里为 CURL 和 NGINX 提供证书以及轮转的，就是 SPIRE 的 Server 和 Agent。

Ghostunnel 是一个简单的 TLS 代理，能为非 TLS 的后端提供双向认证能力。Ghostunnel 能够以服务端（反向代理）或者客户端（代理）的模式进行工作，类似 stunnel。不同的是，他还支持访问控制、证书轮转、ACME 以及最近总在唠叨的 SPIFFE。

本文中会演示的过程实际上是 Ghostunnel 的 SPIFFE DEMO 的一个精简版，会略细致讲述每个步骤涉及的内容。整个过程分为如下一些环节：

环境准备：准备运行环境，包括 SPIRE Agent/Server 的构建、NGINX 的安装、以及 Ghostunnel 的构建等
编写 SPIRE Server 配置，并启动
生成 Ghostunnel 以及 CURL 的 Agent Token，并编写配置文件启动对应的 SPIRE Agent
启动 Ghostunnel
获取 CURL 客户端证书并测试连接

环境准备

这里使用的是基于 ARM 的一个 Ubuntu 系统，使用 APT 安装并启动 NGINX。另外后续步骤还需要 GIT 工具以及连接 GITHUB，并使用 GOLANG 构建 SPIRE 以及 Ghostunnel。

GIT 获取 SPIRE 版本，并进行构建：

$ git clone --single-branch --branch v1.4.0 https://github.com/spiffe/spire.git
Cloning into 'spire'...
...
$ cd spire
$ make bin/spire-agent
Installing go1.18.4...
Building bin/spire-agent...
$ make bin/spire-server
Building bin/spire-server...

接下来获取 Ghostunnel 并进行构建：

$ git clone https://github.com/ghostunnel/ghostunnel.git
Cloning into 'ghostunnel'...
...
$ make ghostunnel
go build -ldflags '-X main.version=v1.6.1-25-g8ae18ea' -o ghostunnel .
...

构建成功后，把三个新生成的可执行文件拷贝到可见目录备用。

spire-101
- certs
- conf
- data
- logs
- socks

编写 SPIRE Server 配置并启动服务

server {
    bind_address = "0.0.0.0"
    bind_port = "8081"
    socket_path = "socks/spire-server.sock"
    trust_domain = "spiffe.dom"
    data_dir = "data/spire-server"
    log_level = "DEBUG"
    ca_ttl = "30m"
    default_svid_ttl = "2m"
    ca_subject = {
        country = ["CN"],
        organization = ["FUNNY"],
        common_name = "",
    }
}

plugins {
    DataStore "sql" {
        plugin_data {
            database_type = "sqlite3"
            connection_string = "data/spire-server/datastore.sqlite3"
        }
    }

    NodeAttestor "join_token" {
        plugin_data {
        }
    }

    KeyManager "disk" {
        plugin_data {
            keys_path = "data/spire-server/keys.json"
        }
    }
}

此处配置文件的几个要点：

TCP 监听 0.0.0.0:8081
监听 Socket 路径为 socks/spire-server.sock
使用 spiffe.dom 作为信任域
SVID 的默认寿命为 2 分钟
使用 SQLite3 作为数据存储引擎，数据库文件保存在 data/spire-server/datastore.sqlite3
在本地存储 Key，路径为 data/spire-server/keys.json。

然后用这个配置文件启动 SPIRE Server：spire-server run -config conf/spire-server.conf > logs/spire-server.log 2>&1 &

启动 Agent

这个小实验需要用到两个 Agent，分别负责服务端和客户端的身份。在运行 Agent 之前，首先要获取 SPIRE Server 的 Trust Bundle：

$ spire-server bundle show \
  -socketPath socks/spire-server.sock > conf/bundle.crt

上述命令将 Trunst Bundle 保存到文件 conf/bundle.crt。

服务端 Agent 配置文件如下：

agent {
    data_dir = "data/server-side-agent"
    log_level = "DEBUG"
    server_address = "127.0.0.1"
    server_port = "8081"
    socket_path ="socks/server-side-agent.sock"
    trust_bundle_path = "conf/bundle.crt"
    trust_domain = "spiffe.dom"
}

plugins {
    NodeAttestor "join_token" {
        plugin_data {
        }
    }
    KeyManager "disk" {
        plugin_data {
            directory = "data/server-side-agent"
        }
   }
   WorkloadAttestor "unix" {
        plugin_data {
             discover_workload_path = true
        }
    }
}

这个配置的要点是：

使用 127.0.0.1:8081 作为 SPIRE Server
监听 socks/spire-server.sock
信任 conf/bundle.crt
Unix Workload Attestor 中开放了选项 discover_workload_path，从而可以通过二进制文件位置或者哈希识别调用 Agent 的应用的身份

为这个 Agent 创建一个 Token，用于标识 Agent 的身份：

$ spire-server token generate \
    -socketPath socks/spire-server.sock \
    -spiffeID spiffe://spiffe.dom/server-node
Token: [Token Hash]

上面命令生成了一个 Token，其 SPIFFE ID 为 spiffe://spiffe.dom/server-node。然后启动服务侧 Agent：

$ spire-agent run \
    -config conf/client-side-agent.conf \
    -joinToken [Token Hash] > logs/client-side-agent.log 2>&1 &

接下来启动客户侧的 Agent，配置文件如下：

agent {
    data_dir = "data/client-side-agent"
    log_level = "DEBUG"
    server_address = "127.0.0.1"
    server_port = "8081"
    socket_path ="socks/client-side-agent.sock"
    trust_bundle_path = "conf/bundle.crt"
    trust_domain = "spiffe.dom"
}

plugins {
    NodeAttestor "join_token" {
        plugin_data {
        }
    }
    KeyManager "disk" {
        plugin_data {
            directory = "data/client-side-agent"
        }
   }
   WorkloadAttestor "unix" {
        plugin_data {
        }
    }
}

跟上面的类似，我们也需要创建 Token 之后才能启动 Agent：

$ spire-server token generate \
    -socketPath socks/spire-server.sock \
    -spiffeID spiffe://spiffe.dom/client-node
Token: [Token Hash]

使用上述 Token 和配置文件启动 Agent：

$ spire-agent run \
    -config conf/client-side-agent.conf \
    -joinToken "$TOKEN" > logs/client-side-agent.log 2>&1 &

启动 Ghostunnel

首先要给 Ghostunnel 一个身份，也就是 Entry：

$ spire-server entry create \
    -selector unix:path:/usr/local/bin/ghostunnel \
    -socketPath socks/spire-server.sock \
    -spiffeID spiffe://spiffe.dom/ghost \
    -parentID spiffe://spiffe.dom/server-node
Entry ID         : fe4b1fd5-9e0a-440b-b08e-5c2c886b6a6e
SPIFFE ID        : spiffe://spiffe.dom/ghost
Parent ID        : spiffe://spiffe.dom/server-node
Revision         : 0
TTL              : default
Selector         : unix:path:/usr/local/bin/ghostunnel

上面的命令参数解释如下：

selector：类似 Kubernetes 中的 Label Selector，用 Workload 属性来界定身份，这里使用的是二进制路径：unix:path:/usr/local/bin/ghostunnel，此文件启动之后，可以使用 Workload API 向 Agent 请求 SVID
socketPath：指定 SPIRE Server 的监听 Socket
spiffeID：Workload 的 SPIFFE ID
parentID：Node 的 SPIFFE ID

创建这个 Entry 之后，SPIRE Server 会据此创建 SVID 下发给 Agent，Agent 只要根据 Selector 判断 Workload 身份，如果符合就可以发放 SVID 了。

接下来启动 Ghostunnel：

$ ghostunnel server \
    --use-workload-api-addr unix:///$(pwd)/socks/server-side-agent.sock \
    --listen=0.0.0.0:9099 \
    --target=localhost:80 \
    --allow-uri=spiffe://spiffe.dom/curl

这里使用了一个参数 --use-workload-api-addr，要求使用 SPIFFE Workload API，对应 Agent Socket 为前面生成的 socks/server-side-agent.sock。--listen 和 --target 分别代表了监听端口和被代理端口（也就是 NGINX）。而 --allow-uri 参数则是一种访问控制手段，此处是允许 spiffe://spiffe.dom/curl 的 SPIFFE ID 访问本服务。除了这种死板的方式之外，Ghostunnel 还能对接 OPA 实现更加复杂的符合生产要求的策略管控能力。

如果此时用浏览器或者 CURL 访问该节点的 9099 端口，就会出现客户端证书不匹配的错误。

获取 CURL 客户端证书并测试连接

类似的，我们给 CURL 创建一个 SVID：

$ spire-server entry create \
    -selector unix:uid:1000 \
    -socketPath socks/spire-server.sock \
    -spiffeID spiffe://spiffe.dom/curl \
    -ttl 600 \
    -parentID spiffe://spiffe.dom/client-node
Entry ID         : 50911ef7-f191-4917-adde-1bf4e6192002
SPIFFE ID        : spiffe://spiffe.dom/curl
Parent ID        : spiffe://spiffe.dom/client-node
Revision         : 0
TTL              : 600
Selector         : unix:uid:1000

因为我们用的是 CURL，并不具备直接访问 Workload API 的能力，所以这里用了比较特别的参数：

Selector 设置为当前用户的 ID，也就是说该用户执行的进程是可以匹配到这个 Entry 从而获取 SVID 的
设置了 10 分钟的 TTL，满足我们后续手动操作的需要

然后用 spire-agent api fetch 的方式获取证书：

$ spire-agent api fetch \
    --socketPath socks/client-side-agent.sock \
    -write certs

命令执行后，会在 certs 发现导出的证书文件，CURL 加上这个证书就能成功访问到 NGINX 了。

$ curl -kv https://127.0.0.1:9099 \
    --cert certs/svid.0.pem --key certs/svid.0.key
*   Trying 127.0.0.1:9099...
* Connected to 127.0.0.1 (127.0.0.1) port 9099 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
...
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
...

然后

如果观察 logs 目录中的日志，会看到在两个 Agent 的目录中会频频出现 Node 和 Workload 的 SVID 轮转的信息。那么如果 Server 挂了呢？这里就会发现，SPIRE Server 是系统中的一个单点，各个 Node 会因为 SVID 无法更新而异常退出，例如：

level=error msg="Agent crashed" error="current SVID has already expired and rotation failed: failed to dial dns:///127.0.0.1:8081: connection error: desc = \"transport: error while dialing: dial tcp 127.0.0.1:8081: connect: connection refused\""

因此需要对 SPIRE Server 进行高可用部署。另外这个手工过程中我们也会看到，手工创建 Entry、传播 Bundle 以及获取证书、参数授权等，是不可能适应快速变更的云服务环境的，因此自动注册机制、策略执行机制以及相应的防篡改机制都是 SPIFFE 体系落地的必要条件。

后续还会根据这些问题进行进一步的尝试。

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

Thu, 11 May 2017 23:27:37 +0800

这次介绍的是在 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🈂️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.yaml 、oidc-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 的 subject 和 audience，并配置 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
}