Kubernetes使用流量管理平台Istio（三）

微服务架构下的安全挑战

为了抵御中间人攻击，需要流量加密。
为了提供灵活的服务访问控制，需要双向TLS和细粒度的访问策略。
要确定谁在什么时候做了什么，需要审计工具。

Istio的安全保证

Istio安全功能提供：

• 身份识别
• 灵活策略
• 透明的TLS加密
• 认证，授权和审计（AAA）工具来保护你的服务和数据

Istio安全的目标是：

• 默认安全： 应用程序代码和基础设施无需更改
• 深度防御： 与现有安全系统集成以提供多层防御
• 零信任网络： 在不受信任的网络上构建安全解决方案

高层架构

• 用于密钥和证书管理的证书颁发机构（CA）
• 配置API服务器分发给代理：
  • 认证策略
  • 授权策略
• 安全命名信息
• Sidecar和边缘代理作为Policy Enforcement Points 以保护客户端和服务器之间的通信安全
• 一组envoy代理扩展，用于管理遥测和审计

Istio安全架构

Istio身份

身份是任何安全基础架构的基本概念。
在工作负载间通信开始时，双方必须交换包含身份信息的凭证以进行双向验证。
在客户端，根据安全命名信息检查服务器的标识，以查看它是否是该服务的授权运行程序。
在服务器端，服务器可以根据授权策略确定客户端可以访问那些信息，审计谁在什么时间访问了什么，根据它们使用的工作负载向客户收费，并拒绝任何未能支付账单的客户访问工作负载。
Istio身份模型使用service identity（服务身份）来确定一个请求源端的身份。

• Kubernetes： Kubernetes服务账户
• GKE/GCE：可以使用GCP服务账户
• GCP：GCP服务账户
• AWS：AWS IAM用户/角色 账户
• On-premises（非Kubernetes）：用户账户、自定义服务账户、服务名称、istio服务账户或GCP服务账户
• Istio安全与SPIFFE：Istio和SPIFFE共享相同的身份文件：SVID（SPIFFE可验证身份证件）。例如： spiffe://domain/ns/namespace/sa/serviceaccount，这使istio服务能够建立和接受与其他SPIFFE兼容系统的连接。

SDS

Istio供应身份是通过secret discovery service（SDS）来实现的：

• istiod提供grpc服务以接受证书签名请求
• 当工作负载启动时，envoy通过秘密发现服务（SDS）API向同容器内的istio-agent发送证书和密钥请求
• 在收到SDS请求后，istio-agent创建私钥和CSR，然后将CSR及其凭据发送到istiod CA进行签名
• istiod CA验证CSR中携带的凭据，成功验证后签署CSR以生成证书
• istio-agent通过envoy SDS API将私钥和从istio CA收到的证书发送给envoy
• istio-agent会监听工作负载证书的有效期，上述CSR过程会周期性地重复，以处理证书和密钥轮换。
  

istio的安全是通过认证和鉴权来保证的，下面会继续向大家介绍！