【问题标题】:Kubernetes authentication with certificate带证书的 Kubernetes 身份验证
【发布时间】:2018-02-13 15:04:39
【问题描述】:

我正在尝试使用证书对本地托管的 Kubernetes 集群 (v1.6.4) 进行身份验证。 这涉及使用Kubernetes plugin for Jenkins 的上下文。

我正在遵循 Kubernetes-plugin README 文件中的 Minikube 指南,我根据我的场景进行了调整:

  1. 将客户端证书转换为 PKCS:

    $ sudo openssl pkcs12 -export -out kubernetes.pfx -inkey /etc/kubernetes/pki/apiserver.key -in /etc/kubernetes/pki/apiserver.crt -certfile /etc/kubernetes/pki/ca.crt -passout pass:jenkins
    
  2. 在 Jenkins 中,使用证书创建凭据

    1. Kind: Certificate
    2. Certificate:Upload PKCS#12 certificate并上传文件kubernetes.pfx
    3. Password: jenkins(在创建证书时指定)
  3. Manage Jenkins -> Add new cloud -> Kubernetes
    1. Kubernetes URL: https://10.179.1.121:6443(作为kubectl config view的输出)
    2. Kubernetes server certificate key:粘贴/etc/kubernetes/pki/ca.crt的内容。
    3. Disable https certificate check:已检查,因为测试设置没有签名证书
    4. Kubernetes Namespace:尝试了defaultkubernetes-plugin
    5. Credentials: CN=kube-apiserver(即上面创建的凭据)

现在当我点击Test Connection 时,这是 Jenkins Web UI 中显示的错误消息:

连接到https://10.179.1.121:6443 时出错:执行失败:GET at:https://10.179.1.121:6443/api/v1/namespaces/kubernetes-plugin/pods。消息:未经授权。

Jenkins 日志显示此消息:

2017 年 9 月 5 日上午 10:22:03 io.fabric8.kubernetes.client.Config tryServiceAccount

警告:从 [/var/run/secrets/kubernetes.io/serviceaccount/token] 读取服务帐户令牌时出错。忽略。

不幸的是,文档主要限于在 Minikube 上运行的 Kubernetes 和 Google Cloud Engine,但我看不出前者与本地托管的 Kubernetes 集群之间存在概念上的差异。

以下用于测试的 Curl 调用会产生非常不同的错误消息:

$ curl --insecure --cacert /etc/kubernetes/pki/ca.crt --cert kubernetex.pfx:secret https://10.179.1.121:6443
User "system:anonymous" cannot get  at the cluster scope. 

更详细:

$ curl -v --insecure --cacert /etc/kubernetes/pki/ca.crt --cert kubernetex.pfx:secret https://10.179.1.121:6443
* About to connect() to 10.179.1.121 port 6443 (#0)
*   Trying 10.179.1.121...
* Connected to 10.179.1.121 (10.179.1.121) port 6443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* skipping SSL peer certificate verification
* NSS: client certificate not found: kubernetex.pfx
* SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate:
*   subject: CN=kube-apiserver
*   start date: Jun 13 11:33:55 2017 GMT
*   expire date: Jun 13 11:33:55 2018 GMT
*   common name: kube-apiserver
*   issuer: CN=kubernetes
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: 10.179.1.121:6443
> Accept: */*
> 
< HTTP/1.1 403 Forbidden
< Content-Type: text/plain
< X-Content-Type-Options: nosniff
< Date: Tue, 05 Sep 2017 10:34:23 GMT
< Content-Length: 57
< 
* Connection #0 to host 10.179.1.121 left intact

我还设置了一个ServiceAccount:

$ kubectl describe serviceaccount --namespace=kubernetes-plugin 
Name:       default
Namespace:  kubernetes-plugin
Labels:     <none>
Annotations:    <none>

Image pull secrets: <none>

Mountable secrets:  default-token-6qwj1

Tokens:             default-token-6qwj1



Name:       jenkins
Namespace:  kubernetes-plugin
Labels:     <none>
Annotations:    <none>

Image pull secrets: <none>

Mountable secrets:  jenkins-token-1d623

Tokens:             jenkins-token-1d623

This question 处理一个相关问题,建议使用 ServiceAccount 或证书,但后一种方法的答案缺少有关如何将 RBAC 配置文件与该证书绑定的详细信息。 Kubernetes documentation about authentication 似乎没有涵盖这个用例。

【问题讨论】:

    标签: authentication ssl jenkins kubernetes kubernetes-security


    【解决方案1】:

    WARNING: Error reading service account token 表示用于加密 ServiceAccount 令牌的密钥在 kube-apiserver (--service-account-key-file) 和 kube-controller-manager 之间不同(--service-account-private-key-file)。如果您的 kube-apiserver 命令行未指定 --service-account-key-file 则使用 --tls-private-key-file 的值,我怀疑这是问题所在。

    我建议始终明确设置 kube-apiserver --service-account-key-file 以匹配 kube-controller-manager --service-account-private-key-file 值。

    【讨论】:

    • 我使用 kubeadm 创建了集群,因此无需手动摆弄这些参数。有什么建议可以在不重新启动 kube-apiserver 的情况下解决此问题?
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-08-07
    • 1970-01-01
    • 2013-08-04
    • 1970-01-01
    • 1970-01-01
    • 2018-10-31
    相关资源
    最近更新 更多