Sur*_*lus 3 kubernetes gitlab-ci-runner
我们gitlab-runner通过kubernetes集群内的kubernetes执行器运行实例(我们称之为KUBE01).这些实例构建并部署到kubernetes集群,并为运行程序提供环境变量KUBECONFIG(指向配置文件),如下所示:
$ cat $KUBECONFIG
---
apiVersion: v1
clusters:
- name: gitlab-deploy
cluster:
server: https://KUBE01:6443
certificate-authority-data: <CA_B64>
contexts:
- name: gitlab-deploy
context:
cluster: gitlab-deploy
namespace: dev
user: gitlab-deploy
current-context: gitlab-deploy
kind: Config
users:
- name: gitlab-deploy
user:
token: gitlab-deploy-token-<secret>
Run Code Online (Sandbox Code Playgroud)
我们可以验证kubectl实际上是否正在使用上述gitlab-deploy上下文:
$ kubectl config current-context
gitlab-deploy
Run Code Online (Sandbox Code Playgroud)
但是,尝试实际影响KUBE01失败:
$ kubectl get pods
error: You must be logged in to the server (Unauthorized)
Run Code Online (Sandbox Code Playgroud)
在我的机器上,我们可以验证命名空间和服务帐户令牌是否正确:
$ kubectl get sa/gitlab-deploy -o yaml --namespace dev
apiVersion: v1
kind: ServiceAccount
metadata:
<snip metadata>
name: gitlab-deploy
namespace: dev
secrets:
- name: gitlab-deploy-token-<secret>
Run Code Online (Sandbox Code Playgroud)
除了它应该工作之外,我找不到任何关于此的文档,并且我发现有关此错误消息的所有论坛/堆栈交换问题都是糟糕的用户/通行证组合; 但据我所知,我的令牌,名称空间和集群都是正确的.
在更详细地阅读了kuberneter身份验证文档和一些反复试验之后,我发现了这个问题.
服务帐户对象内的"秘密令牌"不是我们用于服务帐户身份验证的实际秘密令牌; 相反,它是一个指向秘密对象的指针,而秘密对象又持有真实(承载)令牌.它可以发现如下:
$ kubectl get secret gitlab-deploy-token-<secret> -o yaml
apiVersion: v1
data:
ca.crt: <CA_B64>
namespace: ZGV2
token: <BEARER_TOKEN_B64>
kind: Secret
metadata:
<snip metadata>
name: gitlab-deploy-token-<secret>
namespace: dev
type: kubernetes.io/service-account-token
Run Code Online (Sandbox Code Playgroud)
当然,承载令牌是base64编码的,因为它是一个秘密; 但奇怪的是,我们不会在我们的KUBECONFIG文件中对其进行base64编码(就像我们使用例如CA一样).因此,我们要做的是找到上面的承载令牌,从base64解码它,并将其作为我们的令牌添加到gitlab-deploy用户下面.然后,身份验证工作.
| 归档时间: |
|
| 查看次数: |
4076 次 |
| 最近记录: |