istio安全之Citadel

Citadel

网格内服务之间TLS
Citadel工作原理
- CA Server
- SDS Server
- Secret Controller
- Monitor
Citadel功能演示
- 开启服务间mTLS
- 使用SDS配置TLS Ingress Gateway

Citadel是 Istio 中负责身份认证和证书管理的核心安全组件，1.5版本之后取消了独立进程，作为一个模块被整合在istiod中。

如图，Istio所希望的是在网格中能够使用mTLS进行授权，而在网格外使用JWT+mTLS进行授权。服务间身份认证是使用mTLS，来源身份验证中则是使用JWT。

网格内服务之间TLS

istio中的服务间tls认证

客户端应用程序容器将纯文本HTTP请求发送到服务器。
客户端代理容器拦截出站请求。
客户端代理与服务器端代理执行TLS握手。此握手包括证书交换。
客户端代理对服务器的证书进行校验，以验证授权身份正在运行服务器。双向mTLS的，服务端也会对客户端证书进行校验。
客户端和服务器建立相互TLS连接，服务器代理将请求转发到服务器应用程序容器。
加密套件
Istio将TLS1.2作为最低TLS版本，为客户端和服务器配置了如下加密套件：
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
AES256-GCM-SHA384
AES128-GCM-SHA256

Citadel工作原理

Citadel主要包括CA Server、SDS Server、Secret Controller、Monitor等模块，它们的工作原理如下。

CA Server

Citadel中的CA签发机构，是一个gRPC服务器，启动时会注册两个 gRPC服务，一个是CreateCertificate，用来签发证书。首先会对请求中的service account token进行验证，验证通过后会对CRS进行签名；另一个是HandleCSR，用来处理CSR请求，该方法目前已被CreateCertificate替代，预计很快将会被干掉。

CA Server管理着4个证书，它们都会挂载到istiod容器的/etc/cacerts/目录下，包含ca证书ca-cert.pem、ca私钥ca-key.pem、ca证书链ca-chain.pem和根证书root-cert.pem
其中，ca证书用于给集群中的工作负载进行签名，即对pilog-agent发起的CSR请求进行签名；ca证书和ca私钥必须由根证书签名；ca证书链是ca证书与根证书之间的信任链。
Citadel给crs签名时使用的证书有两个来源：

默认使用自动生成的自签名证书，名为istio-ca-secret的secret
2.用户手动插入自己的CA作为根证书，具体方式是在部署istio之前在istio-system中创建名为cacerts的secret，然后istio部署的时候会自动使用这个secret中的证书
插入CA的具体方法可参考官网文档：https://istio.io/latest/zh/docs/tasks/security/cert-management/plugin-ca-cert

SDS Server

SDS即安全发现服务（Secret discovery service），它是一种在运行时动态获取证书私钥的API，Envoy通过SDS动态获取证书私钥。Istio中的SDS服务器负责证书管理，并实现了安全配置的自动化。相比传统的方式，使用SDS主要有以下优点：

无需重启，就可以动态的新增、删除或者更新密钥/证书对以及根证书。
无需加载Secret卷。创建了kubernetes Secret之后，这个Secret就会被Gateway代理捕获，并以密钥/证书对和根证书的形式发送给 Ingress Gateway。
Gateway代理能够监视多个密钥/证书对。只需要为每个server创建 Secret并更新Gateway定义就可以了

服务间mTLS使用SDS交互流程：

当Envoy进程在与其它Envoy进程交互时，发现需要进行TLS认证，它会从静态配置文件或者动态配置服务器获取证书的名称等相关信息，这时Envoy就会向pilot-agent发起一个SDS请求，要求获取自己的证书和私钥。
pilot-agent收到请求后，会首先读取本地的ServiceAccount Token，路径为/var/run/secrets/kubernetes.io/serviceaccount/token，然后从token中解析出namespace和ServiceAccount等信息，再用这些信息生成私钥和证书签名请求CSR文件。接下来会向Istiod(的Citadel)发起申请证书签名的请求，请求中包含CSR和该pod的service account token
Istiod中的CA Server收到请求后会调用 Kube-apiserver 接口验证请求中附带的 service account token，以确认请求证书的服务身份是否合法，通过后会对根据请求对证书进行签名、生成证书，并将签名后的数字证书发送给SDS Server。
SDS Server将私钥和从CA Server处获得的证书一起通过SDS API发送给Envoy。
以上过程会周期性地重复执行以便实现证书的轮换。
PS：
- 除了Kubernetes之外， Istio也支持虚机部署，在虚机部署的场景下，由于没有service account，因此CA Server的验证pilot-agent请求身份的authenticator接口有三种实现，除了sevice account之外，还支持ID token和tls的方式
- SDS Server和CA Server之间通信时，也是需要互相验证对方身份，此时双方使用的公共CA便是k8s中一个名为istio-ca-root-cert的ConfigMap，此configmap在注入sidecar时会挂载到sidecar的/var/run/secrets/istio目录下，在双方交互时会使用该证书来验证对方证书的签名。

Secret Controller

在kubernetes场景下，需要使用卷挂载方式为SideCar提供证书密钥时，secretController才会被创建和启动。 SecretController监听 istio.io/key-and-cert 类型的 Secret 资源，它会周期性的检查证书是否过期，并更新证书。

如果没有自动证书轮换功能，当证书过期时，就不得不重启签发，并重启代理。证书轮换解决了这一问题，提高了服务的可用性。Istio 里通过一个轮换器（Rotator）自动检查自签名的根证书，并在证书即将过期时进行更新，它本质上是一个协程（goroutine）在后台轮询实现的：
- 获取当前证书，解析证书的有效期并获取下一次轮换时间
- 启动定时器，如果发现证书到达轮换时间，从CA获取最新的证书密钥对
- 更新证书

Monitor

monitor负责注册exporter等工作，为promethus提供性能和指标分析

Citadel功能演示

开启服务间mTLS

在istio中有个peerauthentications的CRD资源，就是通过创建和配置这个资源来开启或关闭istio服务间双向tls认证的：

mtls支持以下模式：

PERMISSIVE：工作负载接受双向TLS和纯文本流量。
STRICT：工作负载仅接受双向TLS通信。
DISABLE：双向TLS已禁用。
缺省情况下，未设置模式的网格范围对等身份验证策略使用PERMISSIVE模式。

开启mtls功能后，可以在sleep服务的pod中curl httpbin服务，在返回的结果中，会看到多了一个"X-Forwarded-Client-Cert"，这便是sidecar为它们添加的证书

使用SDS配置TLS Ingress Gateway

当前版本中，istio默认开启了SDS功能，所以开始配置前，需要先做以下准备工作：

先用自己的CA证书和私钥，为IngressGateway创建Secret：

kubectl create -n istio-system secret generic httpbin-credential \
--from-file=key=httpbin.example.com/3_application/private/httpbin.example.com.key.pem \
--from-file=cert=httpbin.example.com/3_application/certs/httpbin.example.com.cert.pem

查询ingressgateway的IP和https端口，并设置环境变量

export INGRESS_HOST=10.60.212.120
export SECURE_INGRESS_PORT=443

配置单向TLS Ingress Gateway

创建一个Gateway ，其servers:字段的端口为443，设置credentialName的值为httpbin-credential。这个值就是Secret的名字。TLS模式设置为SIMPLE

$ cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:name: mygateway
spec:selector:istio: ingressgateway # use istio default ingress gatewayservers:- port:number: 443name: httpsprotocol: HTTPStls:mode: SIMPLEcredentialName: "httpbin-credential" # must be the same as secrethosts:- "httpbin.example.com"
EOF

配置Gateway的Ingress流量路由，并配置对应的VirtualService：

$ cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: httpbin
spec:
hosts:
- "httpbin.example.com"
gateways:
- mygateway
http:
- match:- uri:prefix: /status- uri:prefix: /delayroute:- destination:port:number: 8000host: httpbin
EOF

用HTTPS协议访问 httpbin 服务：

curl -v -HHost:httpbin.example.com \
--resolve httpbin.example.com:$SECURE_INGRESS_PORT:$INGRESS_HOST \
--cacert httpbin.example.com/2_intermediate/certs/ca-chain.cert.pem \
https://httpbin.example.com:$SECURE_INGRESS_PORT/status/418

httpbin 服务会返回 418 I’m a Teapot。

删除Gateway的Secret，并新建另外一个，然后修改Ingress Gateway的凭据：

kubectl -n istio-system delete secret httpbin-credential

kubectl create -n istio-system secret generic httpbin-credential \
--from-file=key=httpbin.new.example.com/3_application/private/httpbin.example.com.key.pem \
--from-file=cert=httpbin.new.example.com/3_application/certs/httpbin.example.com.cert.pem

使用新证书curl访问httpbin服务：

curl -v -HHost:httpbin.example.com \
--resolve httpbin.example.com:$SECURE_INGRESS_PORT:$INGRESS_HOST \
--cacert httpbin.new.example.com/2_intermediate/certs/ca-chain.cert.pem \
https://httpbin.example.com:$SECURE_INGRESS_PORT/status/418

如果尝试使用之前的证书链来再次访问httpbin，就会得到失败的结果：

curl -v -HHost:httpbin.example.com \
--resolve httpbin.example.com:$SECURE_INGRESS_PORT:$INGRESS_HOST \
--cacert httpbin.example.com/2_intermediate/certs/ca-chain.cert.pem \
https://httpbin.example.com:$SECURE_INGRESS_PORT/status/418

配置双向TLS Ingress Gateway
可以对Gateway的定义进行扩展，加入双向TLS的支持。要修改Ingress Gateway的凭据，就要删除并重建对应的Secret。服务器会使用CA证书对客户端进行校验，因此需要使用cacert字段来保存 CA 证书：

kubectl -n istio-system delete secret httpbin-credential

kubectl create -n istio-system secret generic httpbin-credential  \
--from-file=key=httpbin.example.com/3_application/private/httpbin.example.com.key.pem \
--from-file=cert=httpbin.example.com/3_application/certs/httpbin.example.com.cert.pem \
--from-file=cacert=httpbin.example.com/2_intermediate/certs/ca-chain.cert.pem

修改Gateway定义，设置TLS的模式为 MUTUAL：

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: mygateway
spec:
selector:istio: ingressgateway # use istio default ingress gateway
servers:
- port:number: 443name: httpsprotocol: HTTPStls:mode: MUTUALcredentialName: "httpbin-credential" # must be the same as secrethosts:- "httpbin.example.com"
EOF

使用前面的方式尝试发出HTTPS请求，会看到失败的过程：

curl -v -HHost:httpbin.example.com \
--resolve httpbin.example.com:$SECURE_INGRESS_PORT:$INGRESS_HOST \
--cacert httpbin.example.com/2_intermediate/certs/ca-chain.cert.pem \
https://httpbin.example.com:$SECURE_INGRESS_PORT/status/418

在curl命令中加入客户端证书和私钥的参数，重新发送请求。（客户端证书参数为–cert，私钥参数为–key）

curl -v -HHost:httpbin.example.com \
--resolve httpbin.example.com:$SECURE_INGRESS_PORT:$INGRESS_HOST \
--cacert httpbin.example.com/2_intermediate/certs/ca-chain.cert.pem \
--cert httpbin.example.com/4_client/certs/httpbin.example.com.cert.pem \
--key httpbin.example.com/4_client/private/httpbin.example.com.key.pem \
https://httpbin.example.com:$SECURE_INGRESS_PORT/status/418

如果不想用httpbin-credential secret来存储所有的凭据, 可以创建两个单独的 secret :
- httpbin-credential 用来存储服务器的秘钥和证书
- httpbin-credential-cacert 用来存储客户端的 CA 证书且一定要有-cacert后缀
  使用以下命令创建两个单独的secret :

kubectl -n istio-system delete secret httpbin-credential

kubectl create -n istio-system secret generic httpbin-credential  \
--from-file=key=httpbin.example.com/3_application/private/httpbin.example.com.key.pem \
--from-file=cert=httpbin.example.com/3_application/certs/httpbin.example.com.cert.pem
kubectl create -n istio-system secret generic httpbin-credential-cacert  \
--from-file=cacert=httpbin.example.com/2_intermediate/certs/ca-chain.cert.pem