旅游网站的长图是怎么做的呀,杭州集团网站建设,四川住房和城乡建设厅网站题库,如何在网站做引流概述 我们已经了解了与具体架构形式无关的业界主流安全概念和技术标准#xff08;如TLS、JWT、OAuth 2等概念#xff09;#xff0c;在上一章节探讨了与微服务运作特点相适应的零信任安全模型。在本节中#xff0c;我们将从实践和编码的角度出发#xff0c;介绍在微服务时…概述 我们已经了解了与具体架构形式无关的业界主流安全概念和技术标准如TLS、JWT、OAuth 2等概念在上一章节探讨了与微服务运作特点相适应的零信任安全模型。在本节中我们将从实践和编码的角度出发介绍在微服务时代以Spring Cloud为例和云原生时代以Istio over Kubernetes为例分别如何实现安全传输、认证和授权。通过这两者的对比我们将探讨在微服务架构下如何将业界的安全技术标准引入并实际落地实现零信任网络下安全的服务访问。
建立信任 零信任网络里不存在默认的信任关系。一切服务调用、资源访问成功与否均需以调用者与提供者间已建立的信任关系为前提。此前我们曾讨论过真实世界里能够达成信任的基本途径不外乎基于共同私密信息的信任和基于权威公证人的信任两种。在网络世界里因为客户端和服务端之间一般没有什么共同私密信息所以真正能采用的就只能是基于权威公证人的信任这种信任有一个标准的名字公开密钥基础设施Public Key Infrastructure, PKI。
PKI 和 TLS PKI是构建传输安全层Transport Layer Security, TLS的必要基础。在任何网络设施都不可信任的假设前提下无论是DNS服务器、代理服务器、负载均衡器还是路由器传输路径上的每一个节点都有可能监听或者篡改通信双方传输的信息。要保证通信过程不受到中间人攻击的威胁启用TLS对传输通道本身进行加密让发送者发出的内容只有接受者可以解密是唯一具备可行性的方案。
TLS的实现
建立TLS传输看似不复杂只要在部署服务器时预置好CA根证书以后用该CA为部署的服务签发TLS证书便可。然而落到实际操作上这事情就属于典型的“必须集中在基础设施中自动进行的安全策略实施点”。面对数量庞大且能够自动扩缩的服务节点依赖运维人员手工去部署和轮换根证书必定是难以为继的。除了随服务节点动态扩缩而来的运维压力外微服务中TLS认证的频次也显著高于传统应用。比起公众互联网中主流的单向TLS认证在零信任网络中往往要启用双向TLS认证即不仅要确认服务端的身份还要确认调用者的身份。
单向TLS认证与双向TLS认证 单向TLS认证只需要服务端提供证书客户端通过服务端证书验证服务器的身份但服务器并不验证客户端的身份。单向TLS用于公开服务即任何客户端都被允许连接到服务进行访问它保护的重点是客户端免遭冒牌服务器的欺骗。 双向TLS认证客户端和服务端双方都要提供证书双方各自通过对方提供的证书来验证对方的身份。双向TLS用于私密服务即服务只允许特定身份的客户端访问除了可以保护客户端不连接到冒牌服务器外也可以保护服务端不遭到非法用户的越权访问。 认证
根据认证的目标对象认证可以分为两种类型一种是以机器作为认证对象即访问服务的流量来源是另外一个服务称为服务认证Peer Authentication直译为“节点认证”另一种是以人为认证对象即访问服务的流量来自于最终用户称为请求认证Request Authentication。无论哪一种认证无论是否有基础设施的支持均需有可行的方案来确定服务调用者的身份建立信任关系才能调用服务。
服务认证
Istio版本的Fenix’s Bookstore采用了双向TLS认证作为服务调用双方的身份认证手段。得益于Istio提供的基础设施的支持我们不需要Google Front End、Application Layer Transport Security这些安全组件也不需要部署PKI和CA甚至无须改动任何代码就可以启用mTLS认证。
mTLS的配置
如果你的分布式系统还没有达到完全云原生的程度其中仍存在部分不受Istio管理即未注入边车的服务端或者客户端你也可以将mTLS传输声明为“宽容模式”Permissive Mode。宽容模式的含义是受Istio管理的服务会允许同时接收纯文本和mTLS两种流量纯文本流量仅用于与那些不受Istio管理的节点进行交互你需要自行解决纯文本流量的认证问题而对于服务网格内部的流量则强制要求使用mTLS加密。
例子配置
以下是一个示例配置
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:name: defaultnamespace: istio-system
spec:mtls:mode: PERMISSIVE用户认证
对于来自最终用户的请求认证Istio版本的Fenix’s Bookstore仍然能做到单纯依靠基础设施解决问题整个认证过程无须应用程序参与。例如通过配置Istio的RequestAuthentication CRD可以对外部用户的请求进行JWT验证从而实现用户认证的自动化和透明化。
RequestAuthentication配置示例
apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:name: request-jwtnamespace: bookstore-servicemesh
spec:jwtRules:- issuer: https://example.comjwksUri: https://example.com/.well-known/jwks.json授权
在零信任网络中服务之间没有固有的信任关系。只有已知的、明确授权的调用者才能访问服务阻止攻击者通过某个服务节点中的代码漏洞来越权调用其他服务。这一原则可阻止攻击者扩大其入侵范围与微服务设计模式中使用断路器、舱壁隔离实现容错来避免雪崩效应类似在安全方面也应当采用这种“互不信任”的模式来减小入侵危害的影响范围。
基于角色的访问控制RBAC
RBAC是一种常见的授权机制通过预定义角色和角色与权限的对应关系来控制用户或服务的访问权限。在Istio中通过配置AuthorizationPolicy CRD可以实现基于角色的访问控制。
AuthorizationPolicy配置示例
以下配置声明了一个授权策略允许具有“admin”角色的用户访问“bookstore-servicemesh”命名空间中的所有服务
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:name: allow-adminnamespace: bookstore-servicemesh
spec:rules:- from:- source:principals: [cluster.local/ns/bookstore-servicemesh/sa/admin]通过上述配置我们可以确保只有具有“admin”角色的用户才能访问指定的服务从而实现细粒度的访问控制提升系统的安全性。
总结
服务安全是零信任网络的重要组成部分通过建立信任、认证和授权等机制可以有效保护微服务系统的安全性。在微服务和云原生环境下通过使用诸如Istio等服务网格技术可以简化安全机制的实现确保系统在任何情况下都能安全运行。尽管实现零信任安全模型需要克服诸多技术和运维挑战但其在提升系统安全性方面的优势无疑是显著的。
