1. Istio安全简介

1.1 Istio安全设计目标

单体应用拆分为微服务之后，提高了开发效率，增加系统系统稳定性，提高运维效率等等一系列的好处，但随之也带来了安全方面的风险，之前都是本地调用，现在都改为走网络协议调用接口。

Istio 安全的目标是：

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

说到底，Istio安全主要有两项功能：即无代码侵入前提下，实现流量加密和AAA（验证、授权、审计）。

流量加密，用来解决零信任网络的问题。
Istio的AAA是在集成现有安全协议/标准之上实现的，这些安全协议/标准包括双向TLS，JWT，OpenID Connect等。

1.2 Istio安全体系架构

这张图显示了Istio安全体系架构，图中非常明确的表示 Istio 所希望的是在网格中能够使用 mTLS 进行授权，而在网格外使用 JWT+mTLS 进行授权。服务间身份认证是使用 mTLS，来源身份验证中则是使用 JWT。

2. Istio身份

身份是任何安全基础架构的基本概念。在工作负载间通信开始时，双方必须交换包含身份信息的凭证以进行双向验证。

在客户端，根据安全命名信息检查服务器的标识，以查看它是否是该服务的授权运行程序。
在服务器端，服务器可以根据授权策略确定客户端可以访问哪些信息，审计谁在什么时间访问了什么，根据他们使用的工作负载向客户收费，并拒绝任何未能支付账单的客户访问工作负载。

Istio 身份模型使用 service identity （服务身份）来确定一个请求源端的身份。这种模型有极好的灵活性和粒度，可以用服务身份来标识人类用户、单个工作负载或一组工作负载。在没有服务身份的平台上，Istio 可以使用其它可以对服务实例进行分组的身份，例如服务名称。

下面的列表展示了在不同平台上可以使用的服务身份：

Kubernetes: Kubernetes service account
AWS: AWS IAM user/role account
本地（非 Kubernetes）：用户帐户、自定义服务帐户、服务名称

3.Istio认证

Istio 提供两种类型的认证：

Peer authentication：用于服务到服务的认证，以验证进行连接的客户端。Istio 提供双向 TLS 作为传输认证的全栈解决方案。对于双向 TLS，Istio 会自动将两个 PEPs 之间的所有流量升级为双向 TLS。
Request authentication：用于最终用户认证，以验证附加到请求的凭据。 Istio 使用 JSON Web Token（JWT）验证启用请求级认证，应用程序负责获取 JWT 凭证并将其附加到请求。

3.1 Peer authentication（双向 TLS 认证）

Istio 通过客户端和服务器端 PEPs 建立服务到服务的通信通道，PEPs 被实现为Envoy 代理。当一个工作负载使用双向 TLS 认证向另一个工作负载发送请求时，该请求的处理方式如下：

Istio 将出站流量从客户端重新路由到客户端的本地 sidecar Envoy。
客户端 Envoy 与服务器端 Envoy 开始双向 TLS 握手。在握手期间，客户端 Envoy 还做了安全命名检查，以验证服务器证书中显示的服务帐户是否被授权运行目标服务。
客户端 Envoy 和服务器端 Envoy 建立了一个双向的 TLS 连接，Istio 将流量从客户端 Envoy 转发到服务器端 Envoy。
授权后，服务器端 Envoy 通过本地 TCP 连接将流量转发到服务器服务。

Istio PKI 使用 X.509 证书为每个工作负载都提供强大的身份标识。可以大规模进行自动化密钥和证书轮换，伴随每个 Envoy 代理都运行着一个 istio-agent 负责证书和密钥的供应。下图显示了这个机制的运行流程。

Envoy 向 pilot-agent 发起一个 SDS (Secret Discovery Service) 请求，要求获取自己的证书和私钥。
Pilot-agent 生成私钥和 CSR （Certificates Signing Request，证书签名请求），向 Istiod 发送证书签发请求，请求中包含 CSR 和该 pod 中服务的身份信息。
Istiod 根据请求中服务的身份信息（Service Account）为其签发证书，将证书返回给 Pilot-agent。
Pilot-agent 将证书和私钥通过 SDS 接口返回给 Envoy。

以下对等身份验证策略要求名称空间中的所有工作负载 foo都使用双向TLS：

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:name: "example-policy"namespace: "foo"
spec:mtls:mode: STRICT

3.2 Request authentication（JWT）

用于最终用户认证，以验证附加到请求的凭据。

Istio 使用 JSON Web Token（JWT）验证启用请求级认证，应用程序负责获取 JWT 凭证并将其附加到请求。

为foo namespace下的httpbin workload添加jwt token

kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:name: "jwt-example"namespace: foo
spec:selector:matchLabels:app: httpbinjwtRules:- issuer: "testing@secure.istio.io"jwksUri: "https://raw.githubusercontent.com/istio/istio/release-1.10/security/tools/jwt/samples/jwks.json"
EOF

配置文件require-jwt，要求所有到httpbin的请求都需要有合法的jwt，且jwt_iss/jwt_sub为 testing@secure.istio.io/testing@secure.istio.io

kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:name: require-jwtnamespace: foo
spec:selector:matchLabels:app: httpbinaction: ALLOWrules:- from:- source:requestPrincipals: ["testing@secure.istio.io/testing@secure.istio.io"]
EOF

无效的jwt token请求会被拒绝

kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c sleep -n foo -- curl "http://httpbin.foo:8000/headers" -sS -o /dev/null -H "Authorization: Bearer invalidToken" -w "%{http_code}\n"
401

有效的jwt token请求被允许

$ TOKEN=$(curl https://raw.githubusercontent.com/istio/istio/release-1.10/security/tools/jwt/samples/demo.jwt -s) && echo "$TOKEN" | cut -d '.' -f2 - | base64 --decode -
{"exp":4685989700,"foo":"bar","iat":1532389700,"iss":"testing@secure.istio.io","sub":"testing@secure.istio.io"}$ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c sleep -n foo -- curl "http://httpbin.foo:8000/headers" -sS -o /dev/null -H "Authorization: Bearer $TOKEN" -w "%{http_code}\n"
200

4. Istio授权

Istio 的授权功能为网格中的工作负载提供网格、命名空间和工作负载级别的访问控制。

对于未应用授权策略的工作负载，Istio 不会执行访问控制，放行所有请求。
要配置授权策略，请创建一个 AuthorizationPolicy 自定义资源。一个授权策略包括选择器（selector），动作（action）和一个规则（rules）列表

以下示例显示了一种授权策略，当发送的请求具有有效的JWT令牌时，该策略允许两个来源（ cluster.local/ns/default/sa/sleep服务帐户和dev名称空间）访问httpbin

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:name: httpbinnamespace: foo
spec:selector:matchLabels:app: httpbinversion: v1action: ALLOWrules:- from:- source:principals: ["cluster.local/ns/default/sa/sleep"]- source:namespaces: ["dev"]to:- operation:methods: ["GET"]when:- key: request.auth.claims[iss]values: ["https://accounts.google.com"]

参考

Istio 安全管理
Istio JWT Token
Istio 安全

Istio安全架构--理解身份/认证/授权相关推荐

[认证授权] 5.OIDC（OpenId Connect）身份认证授权（扩展部分）
[认证授权] 5.OIDC(OpenId Connect)身份认证授权(扩展部分) 原文:[认证授权] 5.OIDC(OpenId Connect)身份认证授权(扩展部分) 在上一篇[认证授权] 4. ...
深入聊聊微服务架构的身份认证问题
从单体应用架构到分布式应用架构再到微服务架构,应用的安全访问在不断的经受考验.为了适应架构的变化.需求的变化,身份认证与鉴权方案也在不断的变革.面对数十个甚至上百个微服务之间的调用,如何保证高效安全的 ...
零信任网络ZTNA及SDP概念理解身份认证安当加密
本文是对云安全联盟发布的<NIST零信任架构>及<SDP标准规范>的学习记录,用一句话总结:零信任是一种安全理念,SDP是一种落地方案. 一.什么是零信任网络传统模型假设:组 ...
Shiro身份认证授权原理
shiro在应用程序中的使用是用Subject为入口的, 最终subject委托给真正的管理者ShiroSecurityMannager Realm是Shiro获得身份认证信息和来源信息的地方(所以这 ...
网络安全第3章身份认证
第3章身份认证与访问控制技术-身份认证 3.1 单机身份认证 1. 基于静态口令的身份认证静态的口令,一般不会改变在初始化阶段,用户生成用户名和口令,系统将用户的用户名和口令进行哈希运算,将哈希 ...
typeorm 修改事务_nest.js + typeORM: 身份认证, 事务管理
nest.js + typeORM: 身份认证, 事务管理知识点 jwt 身份认证 md5 加密 typeorm 事务 (transaction) 的使用本文会延续上一篇文章 https://ww ...
基于.NetCore3.1搭建项目系列 —— 认证授权方案之Swagger加锁
1 开始在之前的使用Swagger做Api文档中,我们已经使用Swagger进行开发接口文档,以及更加方便的使用.这一转换,让更多的接口可以以通俗易懂的方式展现给开发人员.而在后续的内容中,为了对a ...
多因素身份认证 (MFA) 插件：手机验证码认证因素配置流程
功能介绍对用户表扩展手机号码字段,允许用户通过手机号码与验证码的方式进行认证,注册,重置密码以及更换手机号. 多因素身份认证 (MFA) 是保护企业 IT 资源访问安全的一种关键工具,也是零信任安全 ...
【Linux】apache的认证授权和访问控制
文章目录前言 ip访问控制 **用户身份认证授权** 主要参数配置案例 a. 创建访问用户及密码 b. 配置文件修改 c. 重启服务 d. 测试前言上篇文章我们探讨了虚拟主机,我们可以通过ip ...

Istio安全架构--理解身份/认证/授权