普适安全生产身份框架SPIFFE-续-摩杜云开发者社区

1、SPIFFE标准包括三个主要组件：

SPIFFE ID：标准化身份名称空间 identity namespace（For JWT-SVIDs, the "sub" claim contains the SPIFFE ID
）
SPIFFE可验证标识文档（SVID）：规定了发布身份的呈现和验证方式 be presented and verified，
工作负载API：指定了API，通过该API可以检索和/或发布身份be retrieved and/or issued（Implementors can verify the authenticity of the caller to the Workload API via an out-of-band method, such as inspecting the properties of the process calling the Unix domain socket that are provided by the operating system.）；除了为工作负载提供必要的SVID之外，Workloadneneneba API还提供了工作负载应该外部信任outwardly trust的CA bundles。这些捆绑包与颁发的SVID之外的信任域相关联，并用于联合 federation。

SPIFFE Workload Endpoint实现负责识别identify调用者caller。然后，SPIFFE Workload API使用有关caller的信息来确定要提供的适当内容

2、使用openssl命令验证工作负载身份与ServiceAccount的绑定。SVID文件中编码了SPIFFE ID: URI:spiffe://cluster.local/ns/bookinfo/sa/default，它被设置为webapp工作负载的"serviceaccount": { "name": "webapp"......z}

# k -n bookinfo exec deploy/webapp -c istio-proxy -- openssl s_client -showcerts -connect catalog.bookinfo.svc.cluster.local:80 -CAfile /var/run/secrets/istio/root-cert.pem | openssl x509 -in /dev/stdin -text -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            82:01:df:b9:1e:9c:a9:14:3f:ca:b5:67:57:6b:71:c2
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: O=cluster.local
        Validity
            Not Before: Oct 24 03:59:40 2023 GMT
            Not After : Oct 25 04:01:40 2023 GMT
X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Authority Key Identifier: 
                keyid:E5:B4:35:3E:70:5E:72:8F:73:CF:8D:50:3A:B4:78:37:C4:1D:83:B2
            X509v3 Subject Alternative Name: critical
                URI:spiffe://cluster.local/ns/bookinfo/sa/default

以上输出的是X509-SVID，将SVID信息编码为X.509证书、必须设置的约束以及如何验证X.509 SVID，参见（https://github.com/spiffe/spiffe/blob/main/standards/X509-SVID.md）的Appendix A. X.509 Field Reference说明。由于TLS被广泛采用，使用X.509作为SPIFFE SVID。
在X.509 SVID中，相应的SPIFFE ID被设置为主题替代名称扩展：SAN扩展（MUST contain exactly one URI SAN）
X.509 extension的basic constraints 标识证书是否是签名证书，以及包括此证书的有效证书路径的最大深度。
：Signing certificates MUST set the CA field to true, and leaf certificates MUST set the cA field to false

depth=1 O = cluster.local
depth=0 
X509v3 Basic Constraints: critical
                CA:FALSE

key usage extension：必须在所有SVID上设置，并且必须标记为关键critical。Leaf SVID必须设置Digital Signature，可以设置keyEncipherment and/or keyAgreement，这些大多只对RSA密钥的证书有意义。

X509v3 Key Usage: critical
                Digital Signature, Key Encipherment

使用openssl verify工具，根据被挂在到istio-proxy容器中的CA根证书（root-cert.pem）检查X509 SVID的签名，显示/dev/fd/63: OK意思是Istio CA签署了该证书，其中的数据是值得信任的。

# k -n bookinfo exec -ti deploy/webapp   -c istio-proxy -- /bin/bash
istio-proxy@webapp-654b79f444-lhd94:/$ openssl verify -CAfile /var/run/secrets/istio/root-cert.pem <(openssl s_client -connect catalog.bookinfo.svc.cluster.local:80  -showcerts  2>/dev/null)
/dev/fd/63: OK

3、Kubernetes 没有自身的用户管理能力，Kubernetes 中的用户通常是通过请求凭证设置，在 Kubernetes 的访问控制流程中用户模型是如何产生的呢？答案就在请求方的访问控制凭证中，也就是我们平时使用的 kube-config 中的证书，或者是 Pod 中引入的 ServerAccount。经过 Kubernetes 认证流程之后，apiserver 会将请求中凭证中的用户身份转化为对应的 User 和 Groups 这样的用户模型。在随后的鉴权操作和审计操作流程中，apiserver 都会使用到该用户模型实例。

Kubernetes支持的请求认证方式主要包括：

Basic 认证
X509 证书认证
Bearer Tokens(JSON Web Tokens)有以下3种形式

JWT Token（Service Account）
基于 OpenID 协议的 Token 认证（OpenID Connect）
Webhooks 方式（Webhooks）

3.1、X509 证书认证方式是 apiserver 中相对应用较多的使用方式，首先访问者会使用由集群 CA 签发的，或是添加在 apiserver Client CA 中授信 CA 签发的客户端证书去访问 apiserver。apiserver 服务端在接收到请求后，会进行 TLS 的握手流程。除了验证证书的合法性，apiserver 还会校验客户端证书的请求源地址等信息。开启双向认证，X509 认证是一个比较安全的方式，也是 Kubernetes 组件之间默认使用的认证方式，同时也是 kubectl 客户端对应的 kube-config 中经常使用到的访问凭证。

普适安全生产身份框架SPIFFE-续_API

可以通过 openssl 命令来进行证书的解析。上图右侧可以看到，通过 Subject 中的 O 和 CN 字段可以查看对应的信息。每一个组件（controller-manager\scheduler\kube-proxy\kubelet）证书都有自己指定的 Common Name 和 Organization 用于特定角色的绑定。

[root@k8s-master01 pki]# openssl x509 -in /etc/kubernetes/pki/ca.pem -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            4a:2f:4b:5a:0f:6b:6b:43:db:b2:3b:e1:19:65:87:a4:40:79:46:df
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=CN, ST=Beijing, L=Beijing, O=Kubernetes, OU=Kubernetes-manual, CN=kubernetes
        Validity
            Not Before: Jun  6 07:32:00 2022 GMT
            Not After : May 13 07:32:00 2122 GMT
        Subject: C=CN, ST=Beijing, L=Beijing, O=Kubernetes, OU=Kubernetes-manual, CN=kubernetes

3.2、Bearer Tokens的JWT Token方式中的 Tokens 是通用的 JWT 的形式，其中包含了签发者、用户的身份、过期时间等多种元信息。它的认证方式也是常见的私钥加签，公钥验签的一个基本流程。基于 Token 的认证使用场景也很广泛，比如 Kubernetes Pod 应用中经常使用到的 Service Account，其中就会自动绑定一个签名后的 JWT Token 用于请求 apiserver。

普适安全生产身份框架SPIFFE-续_Endpoint_02

在部署一个应用时，我们可以通过 template -> spec -> containers 中的 serviceAccountName 字段声明需要使用的 Service Account 名称。注意如果是在 Pod 创建过程中，发现制定的 ServiceAccount 不存在，则该 Pod 创建过程会被终止。在生成的 pod 模板中可以看到指定 serviceaccount 对应的 secret 中的 ca，namespace 和认证 token 会以文件的形式挂载到容器中的指定目录下。另外对于已经创建的 Pod，我们不能更新其已经挂载的 ServiceAccount 内容。

[root@k8s-master01 ~]#  k -n bookinfo exec -ti  deploy/webapp -c webapp -- sh
/go/src/github.com/istioinaction # cd /var/run/secrets/kubernetes.io/serviceaccount
/run/secrets/kubernetes.io/serviceaccount # ls
ca.crt  namespace  token

下图是webapp工作负载token的Decoded内容（包含"serviceaccount"）：

普适安全生产身份框架SPIFFE-续_Endpoint_03

普适安全生产身份框架SPIFFE-续_Endpoint_04

4、