本文主要给大家简单讲讲实现Istio13：Istio基础认证讲析，相关专业术语大家可以上网查查或者找一些相关书籍补充一下，这里就不涉猎了，我们就直奔实现Istio13：Istio基础认证讲析主题吧，希望可以给大家带来一些实际帮助。
前言
微服务架构提供了更好的灵活性、可伸缩性以及服务复用的能力，但，微服务也有特殊的安全需求，Istio Security尝试提供全面的安全解决方案。为了提供灵活的服务访问控制，需要双向 TLS 和细粒度的访问策略。Istio 提供两种类型的身份验证：传输身份验证和来源身份验证。通过配置不同级别的认证策略，可以快速控制不同的安全访问粒度。
典型的使用场景：
1.在未启用双向TLS的安装好 Istio 的 Kubernetes 集群中，需要快速启用全网格双向TLS；
2.网格内某些服务之间需要使用双向TLS，可以将这些服务放入同一命名空间并在命名空间启用双向TLS；
3.当单个服务需要启用TLS时，可以在配置策略中通过spec字段指定；
认证策略是对服务收到的请求生效的，要在双向 TLS 中指定客户端认证策略，需要在DetinationRule 中设置 TLSSettings，每个认证策略需要和目的地规则共同生效。下面通过实例来演示在不同存储范围内配置传输身份认证策略的过程，来源身份验证通过spec中的origins字段指定。
环境准备：装好istio的集群，禁用全局双向TLS；Httpbin应用镜像和sleep应用镜像
1.创建命名空间、部署应用
创建3个命名空间：foo、bar、legacy，foo和bar中部署带sidecar的httpbin应用和sleep应用，legacy中部署不带sidecar的httpbin应用和sleep应用。
将sleep作为客户端，httpbin作为服务端，验证客户端服务端可达性
2.验证系统中目前不存在认证策略
可以看到在foo、bar和legacy命名空间中没有任何策略和规则
3.为网格中的所有服务启用双向TLS认证
配置网格认证策略：
配置目的地规则：
需要注意的是，网格范围内的认证策略名称必须是default，其它名称的策略都会被拒绝和忽视，它的策略类型是MeshPolicy，不同于其它级别的策略类型
这些认证策略和目的地规则有效地配置了所有的sidecars，使服务在双向TLS模式下收发请求。但是对不带sidecar的服务并不适用。
可以看到上面有两种连接不适用：从带有 sidecar 的客户端到不带 sidecar 的服务端的连接以及从不带 sidecar 的客户端到带有 sidecar 的服务端的连接。
① 为了修复从带有 sidecar 的客户端到不带 sidecar 的服务端的连接，可以专门为这些服务端添加目的地规则来覆盖 TLS 设置：
重新测试连接
当启用全局双向 TLS 认证时，这种方法也可以用来配置 Kubernetes 的 API 云服务器。
② 从不带 sidecar 的客户端到带有 sidecar 的服务端(工作在双向 TLS 模式)的连接，唯一的选择是从双向 TLS 模式切换到 PERMISSIVE 模式，该模式允许服务端接收 HTTP 或（双向） TLS 流量
从 sleep.legacy 到 httpbin.foo 的请求应当是成功的，但是到 httpbin.bar 的请求依然会失败。
- 为一个命名空间中的所有服务启用双向TLS
可以配置策略为每一个命名空间单独启用双向 TLS 而不必启用全局双向 TLS：
注意：命名空间范围内的策略必须命名为 default，并且不限定任何特定的服务（没有 targets 设置域）
添加相应的目的地规则：
测试连接：
由于当前配置的策略和目的地规则只对命名空间foo有效，可以看到，只有从不带 sidecar 的客户端 (sleep.legacy) 到 httpbin.foo 的请求会失败。
5.为单个服务启用双向TLS
你也可以为某个特定的服务设置认证策略和目的地规则。执行以下命令只为 httpbin.bar 服务新增一项策略。
配置目的地规则：
- 同时启用命名空间层级和服务层级
假设我们已经为命名空间 foo 中所有的服务添加了启用双向 TLS 的命名空间层级的策略并且观察到从 sleep.legacy 到 httpbin.foo 的请求都失败了（见上文）。现在专门为 httpbin 服务添加额外的策略来禁用双向 TLS （peers 域留空）：
可以看到服务层级的策略覆盖了命名空间层级的策略，连接成功。
对于以上关于实现Istio13：Istio基础认证讲析，大家是不是觉得非常有帮助。如果需要了解更多内容，请继续关注我们的行业资讯，相信你会喜欢上这些内容的。