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