☰

kubeconfig 文件的自定义根证书

tag-icon • tag-icon kubernetes kubeadm
kubeconfig 文件的自定义根证书

跑步kubeadm init phase certs apiserver --config kubeadm.yaml

是否可以为用户组/kubectl/config 文件使用多个/自定义根证书？

我之所以询问，是因为我想根据每个项目授予访问权限 - 然后删除自定义根证书 - 但保留特殊的 kubectl 管理员的“原始”根证书。

我已经看到您可以使用 ssh 隧道作为第一道防线，以保护根证书公钥。但您仍然需要分发公共签名证书，即使它位于 ssh 公钥私钥后面。因此，也许有一种方法可以绕过使用 ssh 隧道 - 并放入自定义证书certificatesDir: /etc/kubernetes/pki？

kubeadm.yaml

apiServer:
  extraArgs:
    authorization-mode: Node,RBAC
  timeoutForControlPlane: 4m0s
apiVersion: kubeadm.k8s.io/v1beta1
certificatesDir: /etc/kubernetes/pki

我知道您可以--insecure-skip-tls-verify在配置文件中使用它，但这似乎是个坏主意。

答案1

是否可以为用户组/kubectl/config 文件使用多个/自定义根证书？

不，只有一个“根”证书，这就是为什么它被称为根。

然而，x509 是一个链信任，这意味着完全有可能在该根下颁发从属 CA，然后在这些 CA 下颁发用户证书，选择在项目结束时删除从属 CA，这将使所有这些叶证书成为孤儿。请注意，据我所知，更改证书或其链需要重新启动控制平面，因为它不会热重载这些证书文件。我相信有一个 GitHub 问题，就像其余 15,000 个问题一样

另一种选择（取决于您的需求）是为用户证书颁发短期租约，这样“撤销”过程就不会改变 x509 信任链，而只是无法重新颁发凭证。这更接近 Hashicorp Vault 和 Let's Encrypt 的思想流派

我个人已经实现了第二个（使用 Vault），但我相信第一个也是可行的，因为 apiserver 使用 x509 链进行一些集群内组件身份验证，所以我不明白为什么你不能同样利用该机制

我知道这不是你想要的，但使用 x509 进行临时身份验证是一条毁灭之路，因为——正如你所经历的——颁发和撤销两方面都非常麻烦。如果你可以使用它，OIDC 身份验证机制更容易推理，并且kubectl或多或少内置支持

相关内容