istio笔记

[humingcheng]

isto mixer rbac笔记： CRD是什么CustomResourceDefinition 自定义资源定义 level role service -> service endUser -> service ServiceRole----这里面的一大堆格则，使用来干嘛的？In ServiceRole, the combination of “namespace”+“services”+“paths”+“methods” defines “how a service (services) is allowed to be accessed”.这更像一种契约，描述一个provider的属性：“namespace”,“service”,“paths”,“methods”。 ServiceRoleBinding-----这是个表格，存储有ServiceRole和一些subjects的对应关系。用来干什么呢？描述了哪些consumer可以访问哪些provider.subject是什么？主语，caller,consumer。

RBAC engin位于mixer，是mixer的一个adapter rbac需要哪些信息？ 这些信息从哪里来？ 对这个图有疑问：https://istio.io/docs/concepts/security/authn-policy/ istio的配置存储在config store中，但是这些配置难道通过pilot下发到所有envoy中？但是后面又说认证的功能由mixer执行，mixer负责从config store中拉取策略信息。

基本概念： template instance

ACL 是啥？ JWT go接入istio后，跟谁打交道？pilot/mixer/envoy?

流程可能是这样的：双向TLS认证，证书从哪里获取呢？ RBAC：consumer在发送请求时带上JWT信息，provider（go/envoy）解析出jwt中的信息后，生成request context，发送给mixer进行校验。 istio里config store是什么东西？ ACL 访问控制列表，一种访问控制模型。PBAC也是一种访问控制模型。 Authentication policies 是什么，具体指什么？为什么它保存在config store里面？为什么它要下发给sidecar?

认证鉴权功能并不集成在sidecar，而是在mixer里，那么sidecar和mixer如何通信，通信内容是什么？我猜是这样的：

• sidecar：这是consumer的信息，检查下他有访问权限么？
• mixer：他没有权限。
• sidecar：拒绝访问。

service account是什么？pod中的进程要访问apiServer，需要带上一个身份用于认证，这个身份就是service account。当然不仅apiserver可以去认证这个身份，pod自己也可以认证别的pod的身份，envoy就是这么干的。识别的目的是什么：识别server端的证书身份是否被允许运行server端。

tls配置项来源

istio-agent or sidecar from lds?

认证的内容具体是什么

进行认证时，文档一边说是server端进行认证，一边又说client要检查server端证书内的身份是否能够运行这个服务端。 确认下client的tls配置中是否有认证对端这一项

https://www.envoyproxy.io/docs/envoy/v1.7.0/intro/arch_overview/ssl client/server的配置

client https://www.envoyproxy.io/docs/envoy/v1.7.0/api-v1/cluster_manager/cluster_ssl#config-cluster-manager-cluster-ssl

{
  "alpn_protocols": "...",
  "cert_chain_file": "...",
  "private_key_file": "...",
  "ca_cert_file": "...",
  "verify_certificate_hash": "...",
  "verify_subject_alt_name": [],
  "cipher_suites": "...",
  "ecdh_curves": "...",
  "sni": "..."
}

server https://www.envoyproxy.io/docs/envoy/v1.7.0/api-v1/listeners/listeners#config-listener-ssl-context

{
  "cert_chain_file": "...",
  "private_key_file": "...",
  "alpn_protocols": "...",
  "alt_alpn_protocols": "...",
  "ca_cert_file": "...",
  "verify_certificate_hash": "...",
  "verify_subject_alt_name": [],
  "crl_file": "...",
  "cipher_suites": "...",
  "ecdh_curves": "...",
  "session_ticket_key_paths": []
}

谁来认证？

• client server端提供的证书中的身份，是否有权限运行该服务端？证书中的身份是至什么？ 在handshake阶段进行该认证么？ client找谁去认证？mixer？
• server client如果提供端证书，其身份是否允许访问我？ 如果不要求client提供证书，那还要验证么？ 如果不要求client认证证书，但是client实际提供了证书，server端认证么 server端找谁去认证？mixer
• Secure Naming: during the handshake process, the client side Envoy checks that the service account provided by the server side certificate is allowed to run the target service istio文档内容，判断一个服务的唯一身份就是service account，但是我还要检查service account是否能云心这个服务。好比某个系统里，指纹是一个人的唯一生物学身份，我咋确认一个指纹就是某个人？ 难道有一个表，可以查到service account和service的权限关系？

与mixer的交互

client/server发送元数据给mixer client/server发送的数据有哪些？mixer认证的方式ishifou相同？ 用rule控制mixer进行认证 client要验证：服务端提供的证书中的身份，是否有权限运行该服务端，这要怎么认证？mixer有这个功能么？ 我只看到访问控制，没看到”运行控制“

不用考虑namespace，当前就仅针对同一个namespace

[humingcheng]

rbac代码解读：

• controller 配置管理器，功能：从config store中更新配置信息

[humingcheng]

pbac策略包括两部分：

• ServiceRole
• ServiceRoleBinding

[humingcheng]

根据mixer代码，认证策略并不是下发到sidecar，而是下发到mixer，sidercar发送ctx至mixer，ctx里包括consumer、provider信息，mixer根据ctx判断是否满足认证要求。

[humingcheng]

根据代码，mixer校验时需要的input是instance，instance是从哪里来的？ 返回值是啥？

[humingcheng]

mixer的不同adapter需要不同的配置，比如后端地址，这些配置定义在一些protobuf message。 对每个sidecar接收到的req.

[humingcheng]

attribute 描述服务、request的一些key value，就是个invocation metadata/context instance：描述了一个数据struct。struct的元素从attributest获取。instance被adapter使用。 template：instance的spec部分。描述adapter的输入数据与attributes数据的对应关系。

handler：描述一个adapter。该adapter的信息和schema（某些配置） rule:何时调用某个handler，并使用某些instance数据。

[humingcheng]

mixer与config-store如何通信？配置信息是下发、watch、还是pull？

[humingcheng]

istio文档里面：Authentication policies are saved in Istio config store (in 0.7, the storage implementation uses Kubernetes CRD), and distributed by control plane. Depending on the size of the mesh, config propagation may take a few seconds to a few minutes. During the transition, you can expect traffic lost or inconsistent authentication results.

这说明"Authentication policies"要下发到sidecar 里面，这"Authentication policies"到底是个啥？为什么要下发到sidecar?

[humingcheng]

go-chassis/mesher对接istio，相当于spring接入cse这种改造。

[humingcheng]

istio与envoy是鸡生蛋的关系，还是并行的关系？

[humingcheng]

auth由sidecar执行，mixer只是提供backend进行协助。 sidecar -- pilot -- config store是如何互通的？

policy 高于具体的认证方式。

ssl setting http filter?

[humingcheng]

双向tls简单一点，只要对接证书。 问题是证书是spiffe相关，先要了解spiffe。 Pilot定义什么服务账户可以运行某个服务，这个是用来干啥的？sidecar解析证书中的身份是否在pilot规定的身份中。 主要就是两部分：加载挂载的证书，解析证书里的身份，与pilot中定义的信息对比。 证书挂载在哪里？ 如何解析证书中的身份信息？ Pilot接口是啥？

[humingcheng]

authentication policy的构成：

• target selector: 本policy适用于哪些service
• peer/origin auth的具体配置
• principal binding 用对方的那个身份，peer/origin

[humingcheng]

sidecar-sidecar, sidecar-istio之间，认真鉴权有什么不同？

[humingcheng]

根据istio的demo，要想开启tls，首先在k8s创建authtication policy，作用于provider；再创建destinationRule，作用于consumer。然后sidecar启用mutual TLS。

[humingcheng]

认证有多个点：sidecar-sidecar, service-sidecar，endusr-sidecar，sidecar-istio，这些分别如何控制，目前只看到sidecar到sidecar

[humingcheng]

Istio uses Kubernetes service accounts as service identity, which offers stronger security than service name (refer here for more information). Thus the certificates used in Istio do not have service names, which is the information that curl needs to verify server identity. As a result, we use curl option -k to prevent the curl client from aborting when failing to find and verify the server name (i.e., httpbin.ns.svc.cluster.local) in the certificate provided by the server.

[humingcheng]

svc-svc之间的tls认证，证书的配置在什么路径？从哪里得知路径？或者路径是固定的？/etc/certs? 如果配置了tls，sidecar是如何得到配置并生效的？通过api of 配置文件？如何让mesher动态感知这些配置？ 1, 配置如何给到envoy? 2,怎么告诉envoy“现在开始用tls”，“现在证书过期了，要更换”，“现在不用tls了” 3，envoy配置更改后，要重启么？ pilot-监控证书变化，如果变化，则重启envoy。 4，如何更换证书？

[humingcheng]

policy配置下发给k8s后，istio如何拿到的？ istio中实现configStore，可以对接k8s（细节未知），从k8s获取auth policy

[humingcheng]

文章：

https://www.kubernetes.org.cn/4208.html

[humingcheng]

pilot中的信息，有部分是通过api传给envoy，有部分是通过配置文件传给envoy，请分别分析。

[humingcheng]

阶段总结：

sidecar - sidecar

• 证书从哪里来？ go的代码不用关心证书来源，创建pod时会挂载，也会自动刷新。就好比envoy也不用关系一样。 让用户手动挂载。
• tls的完整配置（证书位置，认真对端，tls协议，加密算法）从哪里获得？ 参考下istio agent，istio agent是用于生成envoy配置的，应该会先拉取相关配置。envoy应该是从pilot拉取的，但是envoy具有配置动态生效能力，我们没有，所以我们就让用户手动配置。
• tls的配置（证书内容，tls enable等）变了怎么办？ 不管他，仅初始化一次。
• 证书加载后就直接通信么？从证书中解析service account
• tls握手过程中要对server进行权限认证

  service-sidecar

  endUser-service

[humingcheng]

envoy TLS 架构

[humingcheng]

envoy中设计的tls知识点 SNI协议 服务器名称指示（英语：Server Name Indication，简称 SNI）是一个扩展的TLS计算机联网协议[1]，在该协议下，在握手过程开始时透过客户端告诉它正在连接的服务器的主机名称。这允许服务器在相同的IP地址和TCP端口号上呈现多个证书，并且因此允许在相同的IP地址上提供多个安全（HTTPS）网站（或其他任何基于TLS的服务），而不需要所有这些站点使用相同的证书。它与HTTP/1.1基于名称的虚拟主机的概念相同，但是用于HTTPS。所需的主机名未加密，[2] 因此窃听者可以查看请求的网站。

ALPN协议

CRL Certificate Revocation List 证书吊销列表 SAN SAN(Subject Alternative Name) 是 SSL 标准 x509 中定义的一个扩展。使用了 SAN 字段的 SSL 证书，可以扩展此证书支持的域名，使得一个证书可以支持多个不同域名的解析。

envoy的tls配置：

{
  "cert_chain_file": "...",#证书
  "private_key_file": "...",#私钥
  "alpn_protocols": "...",#alpn协议？
  "alt_alpn_protocols": "...",#?
  "ca_cert_file": "...",#信任证书
  "verify_certificate_hash": "...",#是否校验证书签名
  "verify_subject_alt_name": [],#SAN列表
  "crl_file": "...", #证书吊销列表文件
  "cipher_suites": "...", #算法列表
  "ecdh_curves": "...",#所使用的ecdh曲线（秘钥交换算法）
  "session_ticket_key_paths": [],#tls握手时session复用的技术，配置在服务端
  "require_client_certificate": ""#（服务端）认证对端
}

[humingcheng]

在对接istio时，go-chassis/mesher如何吸引用户： 提供显著高于envoy和其他对接envoy的sicecar的性能，同时在开发难度、易用性、istio功能性上不能差太多（不能抵消性能优势）。 目前性能上的确显著高于envoy。 在功能性上，与envoy的差别：

• 证书刷新后重启，无法重启
• tls配置刷新后可动态生效，无法生效
• 证书可自动挂载- 手动挂载

[humingcheng]

什么是”认证“，认证的根本目的是什么？ TLS的根本目的是什么？与”认证“是否有交集？ 通信的安全风险为三类：

• 窃听 通过TLS非对称加密
• 篡改 签名
• 冒充 证书 以上是”通信“的安全性，即peer-peer 另外还有源安全性，即要保证发起通信的那个人，是我的人。即origin认证，这需要给这个人一个身份，这个身份有别于一个机器的身份。 证书中的身份比较固定，一般是ip/域名/服务，如果要用户的身份，一般用别的认证方式。

[humingcheng]

控制面用tls 数据面用tls和jwt

[humingcheng]

先进行tls双向认证吧

• envoy的tls配置项，client端并没有区分不同server。比如verify_alt_name，如果client要访问100个server，这个咋配置，配100个？ envoy也是针对不同provider进行配置的：见cluster manager的配置：https://www.envoyproxy.io/docs/envoy/v1.7.0/api-v1/cluster_manager/cluster_manager 内容如下，clusters的列表里装的就是不同provider的配置

  {
  "clusters": [],
  "sds": "{...}",
  "local_cluster_name": "...",
  "outlier_detection": "{...}",
  "cds": "{...}"
  }

  首先确认方案： istio的认证内容很多很复杂，包含peer（mtls）和origin。 gosdk只有tls，而且配置项少于istio的。没有origin的认证。 istio的peer/origin最后都要对接到rbac，这个gosdk也还没有做。

• 第一步是把tls的配置项对上，配置项对应的功能加上。 但是双向认证不能加上，因为spiffe下的证书，其SAN字段与host是不匹配的。
• 第二步是tls对接rbac。 解析spiffe，同时对接rbac进行。
• 第三步是加入jwt认证，并对接rbac。

[humingcheng]

go/envoy存在的差异：

client

gosdk有verify_peer，envoy没有

server

go有verifypeer，envoy没有，但是有verify_subject_alt_name和require_client_certificate

client/server

envoy都没有说明如何配置控制面的tls 有，控制面的这么一坨配置里有ssl_context，和sidecar-sidecar之间的ssl_context一样：

{
  "name": "...",
  "type": "...",
  "connect_timeout_ms": "...",
  "per_connection_buffer_limit_bytes": "...",
  "lb_type": "...",
  "ring_hash_lb_config": "{...}",
  "hosts": [],
  "service_name": "...",
  "health_check": "{...}",
  "max_requests_per_connection": "...",
  "circuit_breakers": "{...}",
  "ssl_context": "{...}",
  "features": "...",
  "http2_settings": "{...}",
  "cleanup_interval_ms": "...",
  "dns_refresh_rate_ms": "...",
  "dns_lookup_family": "...",
  "dns_resolvers": [],
  "outlier_detection": "{...}"
}