zoukankan      html  css  js  c++  java
  • kubernete的证书总结

    服务端保留公钥和私钥,客户端使用root CA认证服务端的公钥。

    kubernetes的证书类型主要分为3类:

    • serving CA: 用于签署serving证书,该证书用于加密https通信。用于签署kubernetes API serving证书的CA也可以用于签署API server插件的serving证书,可能会用到不同的CA
    • client CA: 用于签署客户端证书,同时也被API server插件用来对客户端发来的证书进行认证。用于签署kubernetes API serving证书的client CA也可以用于签署API server插件的serving证书,可能会用到不同的CA
    • RequestHeader client CA: 该CA用于签署API server代理客户端证书,拥有代理证书的客户端可以有效地伪装成任何身份。当运行在aggregator之后时,该CA必须与前述aggregator代理客户端证书的CA一致()

    serving 证书:
    --tls-cert-file和--tls-private-key-file,API server用这两个选项来认证连接到自己的TLS。这两个证书也是CA(可以是自签CA)签署的。由于客户端节点可能会拒绝自签CA,因此需要将该CA分发给客户端节点,并在客户端指定该CA。如下kubelet的kubeconfig中的certificate-authority就指定了用于认证tls证书的CA。--tls-cert-file中需要有server字段的名称。API server和kubelet(当需要认证到kubelet的请求时)都有这两个选项,工作原理一样。

    current-context: my-context
    apiVersion: v1
    clusters:
    - cluster:
    certificate-authority: /path/to/my/ca.crt # CERTIFICATE AUTHORITY THAT ISSUED YOUR TLS CERT
    server: https://horse.org:4443 # this name needs to be on the certificate in --tls-cert-file
    name: my-cluster
    kind: Config
    users:
    - name: green-user
    user:
    client-certificate: path/to/my/client/cert
    client-key: path/to/my/client/key

    client 证书:
    --client-ca-file:任何带有 client-ca-file 签名的客户端证书的请求,都将通过客户端证书中 Common Name 对应的标识进行身份认证,证书中的 Common Name 会作为用户名,Organization作为组来使用。默认情况下,API Server使用该选项会自动创建一个名为extension-apiserver-authentication,位于kube-system命名空间的ConfigMap ,该ConfigMap 中包含了--client-ca-file指定的CA。
    API server的--kubelet-certificate-authority、--kubelet-client-certificate、--kubelet-client-key 和kubelet的--client-ca-file为一组选项,用于对kubelet进行认证(kubelet 组件在工作时,采用主动的查询机制,即定期请求 apiserver 获取自己所应当处理的任务)

    RequestHeader client CA:
    主要涉及3个选项--requestheader-client-ca-file、--proxy-client-cert-file、--proxy-client-key-file。代理(如aggregator)使用--proxy-client-cert-file、--proxy-client-key-file来请求API Server,API Server使用--requestheader-client-ca-file指定的证书来认证代理的证书。这三个选项都设置在API server的flag中,即aggregator一方面作为API server认证来自client的证书,一方面作为client,使用自身的代理证书向API server请求认证。
    当kubernetes对应的客户端证书中的usernames和group与自己需求不符合时(无法认证或权限不足等),可以使用认证代理(代理使用另一套证书请求API server)

    可以看到serving证书是通过TLS来进行认证,client证书通过用户名(Common Name)和组(Organization)进行认证;RequestHeader client证书认证方式与client证书认证方式类似

    证书的验证:

    显示插件API server支持的证书:openssl s_client -connect <service-cluster-ip>:443更多

    验证证书是否由CA签署:openssl verify -CAfile ca.crt   the-certificate.crt

    更多参见Certificate Issues

    serviceaccount:参见http://www.cnblogs.com/charlieroro/p/8484711.html中serviceaccount一节

    参考

    https://jvns.ca/blog/2017/08/05/how-kubernetes-certificates-work/
    https://kubernetes.io/docs/concepts/cluster-administration/certificates

  • 相关阅读:
    html页面怎样能够自适应电脑屏幕宽度
    js语法大全
    DevExtreme- jQuery 表格组件-DataGrid
    DevExtreme 图表组件
    C# 中的委托和事件
    SQL Server游标的使用
    Oracle11g使用exp导出空表
    PowerDesigner设计Name和Comment 替换
    Toad for Oracle 快捷键
    Windows 命令大全
  • 原文地址:https://www.cnblogs.com/charlieroro/p/9791240.html
Copyright © 2011-2022 走看看