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。