九 Istio：istio安全之授权 _生活百科

一.模块概览
二.系统环境
三.istio授权
- 3.1 istio授权
- 3.2 来源
- 3.3 操作
- 3.4 条件
四.实战：授权（访问控制）
- 4.1 访问控制
- 4.2 清理

一.模块概览在Kubernetes集群中，可以对用户进行RBAC授权role，rolebinding，clusterrole ， clusterrolebinding；对于istio来说，可以对资源定义AuthorizationPolicy授权策略，执行拒绝、允许或审计动作。
在 Istio 中，有多个组件参与提供安全功能：

用于管理钥匙和证书的证书颁发机构（CA）。
Sidecar 和周边代理：实现客户端和服务器之间的安全通信，它们作为政策执行点（Policy Enforcement Point，简称PEP）工作
Envoy 代理扩展：管理遥测和审计
配置 API 服务器：分发认证、授权策略和安全命名信息

istio授权是在认证通过之后进行的，关于istio认证，可以查看博客《Istio(八)：istio安全之认证，启用mTLS》https://www.cnblogs.com/renshengdezheli/p/16840382.html
使用istio授权的前提是已经安装好了istio，关于istio的安装部署，请查看博客《Istio(二)：在Kubernetes(k8s)集群上安装部署istio1.14》https://www.cnblogs.com/renshengdezheli/p/16836404.html
二.系统环境服务器版本docker软件版本Kubernetes(k8s)集群版本Istio软件版本CPU架构CentOS Linux release 7.4.1708 (Core)Docker version 20.10.12v1.21.9Istio1.14x86_64Kubernetes集群架构：k8scloude1作为master节点， k8scloude2，k8scloude3作为worker节点
服务器操作系统版本CPU架构进程功能描述k8scloude1/192.168.110.130CentOS Linux release 7.4.1708 (Core)x86_64docker ， kube-apiserver，etcd ， kube-scheduler，kube-controller-manager，kubelet ， kube-proxy ， coredns，calicok8s master节点k8scloude2/192.168.110.129CentOS Linux release 7.4.1708 (Core)x86_64docker ， kubelet，kube-proxy，calicok8s worker节点k8scloude3/192.168.110.128CentOS Linux release 7.4.1708 (Core)x86_64docker ， kubelet，kube-proxy，calicok8s worker节点三.istio授权3.1 istio授权授权是对访问控制问题中访问控制部分的响应。某个（经过认证的）主体是否被允许操作某个对象？用户 A 能否向服务 B 的路径 /hello 发送一个 GET 请求？
请注意，尽管主体可以被认证，但它可能不被允许执行某个动作。你的公司 ID 卡可能是有效的、真实的，但我不能用它来进入另一家公司的办公室。如果我们继续之前的海关官员的比喻，我们可以说授权类似于你护照上的签证章。
这就引出了下一个问题 —— 有认证而无授权（反之亦然）对我们没有什么好处。对于适当的访问控制，我们需要两者。让我给你举个例子：如果我们只认证主体而不授权他们，他们就可以做任何他们想做的事，对任何对象执行任何操作。相反，如果我们授权了一个请求，但我们没有认证它，我们就可以假装成其他人，再次对任何对象执行任何操作。
Istio 允许我们使用 AuthorizationPolicy 资源在网格、命名空间和工作负载层面定义访问控制。AuthorizationPolicy 支持 DENY、ALLOW、AUDIT 和 CUSTOM 操作。
每个 Envoy 代理实例都运行一个授权引擎，在运行时对请求进行授权。当请求到达代理时，引擎会根据授权策略评估请求的上下文，并返回 ALLOW 或 DENY 。AUDIT 动作决定是否记录符合规则的请求。注意，AUDIT 策略并不影响请求被允许或拒绝。
没有必要明确地启用授权功能。为了执行访问控制，我们可以创建一个授权策略来应用于我们的工作负载。
AuthorizationPolicy 资源是我们可以利用 PeerAuthentication 策略和 RequestAuthentication 策略中的主体的地方。
在定义 AuthorizationPolicy 的时候，我们需要考虑三个部分。

选择要应用该策略的工作负载
要采取的行动（拒绝、允许或审计）
采取该行动的规则

让我们看看下面这个例子如何与 AuthorizationPolicy 资源中的字段相对应。
【九 Istio：istio安全之授权】

 apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata:name: customers-denynamespace: default spec:selector:matchLabels:app: customersversion: v2action: DENYrules:- from:- source:notNamespaces: ["default"]

使用 selector 和 matchLabels，我们可以选择策略所适用的工作负载。在我们的案例中，我们选择的是所有设置了 app: customers 和