我正在尝试访问我自己托管的gitlab实例中的kubernetes集群，正如文档中所描述的。
deploy:
stage: deployment
script:
- kubectl create secret docker-registry gitlab-registry --docker-server="$CI_REGISTRY" --docker-username="$CI_DEPLOY_USER" --docker-password="$CI_DEPLOY_PASSWORD" --docker-email="$GITLAB_USER_EMAIL" -o yaml --dry-run=client | kubectl apply -f -
但是我得到了错误
Error from server (Forbidden): error when retrieving current configuration of:
Resource: "/v1, Resource=secrets", GroupVersionKind: "/v1, Kind=Secret"
Name: "gitlab-registry", Namespace: "gitlab"
from server for: "STDIN": secrets "gitlab-registry" is forbidden: User "system:serviceaccount:gitlab:default" cannot get resource "secrets" in API group "" in the namespace "gitlab"
我不明白这个错误。为什么会出现禁止错误?
更新
kubernetes集群在实例级集成在gitlab中。
但是在CI管道中运行kubectl config view会得到
apiVersion: v1
clusters: null
contexts: null
current-context: ""
kind: Config
preferences: {}
users: null
更新2
多亏了AndD，秘密可以用这个角色/服务帐户创建:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
namespace: gitlab
name: gitlab-deploy
rules:
- apiGroups: [""] # "" indicates the core API group
resources: ["secrets"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: use-secrets
namespace: gitlab
subjects:
- kind: ServiceAccount
name: default
namespace: gitlab
roleRef:
kind: ClusterRole
name: gitlab-deploy
apiGroup: rbac.authorization.k8s.io
但是运行这个名称空间的简单应用程序。yaml文件
apiVersion: v1
kind: Namespace
metadata:
name: myns
给出了类似的错误:
Error from server (Forbidden): error when retrieving current configuration of:
Resource: "/v1, Resource=namespaces", GroupVersionKind: "/v1, Kind=Namespace"
Name: "myns", Namespace: ""
from server for: "namespace.yaml": namespaces "myns" is forbidden: User "system:serviceaccount:gitlab:default" cannot get resource "namespaces" in API group "" in the namespace "myns"
我使用了ClusterBinding，即使对于不同的名称空间也是如此。我做错了什么?
Kubernetes使用基于角色的访问控制(RBAC)来防止pod和用户能够与集群中的资源交互，除非他们未经授权。
从错误中，您可以看到Gitlab正在尝试使用secrets资源，并且它在其命名空间中使用default服务帐户作为ServiceAccount。
这意味着Gitlab没有配置为使用特定的ServiceAccount，这意味着它使用默认的服务帐户(在集群的每个名称空间中都有一个默认的服务帐户)
可以通过Role/ClusterRole和RoleBinding/ClusterRoleBinding为业务帐户附加角色认证和权限。
Roles或ClusterRoles描述权限。例如，角色可以是:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: gitlab
name: secret-user
rules:
- apiGroups: [""] # "" indicates the core API group
resources: ["secrets"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
，这表明"谁拥有这个角色，可以对秘密做任何事情(所有动词)，但只能在gitlab">
如果您想在所有名称空间中提供通用权限，您可以使用ClusterRole代替，这非常类似。
创建角色后，您可以将其附加到用户、组或服务帐户，例如:
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: use-secrets
namespace: gitlab
subjects:
subjects:
- kind: ServiceAccount
name: default
namespace: gitlab
roleRef:
# "roleRef" specifies the binding to a Role / ClusterRole
kind: Role # this must be Role or ClusterRole
name: secret-user # this must match the name of the Role or ClusterRole you wish to bind to
apiGroup: rbac.authorization.k8s.io
，这将之前创建的角色绑定到命名空间gitlab中称为default的ServiceAccount。
所有,运行在命名空间gitlab中并使用default服务帐户的pod将能够使用secrets(使用角色中列出的动词)，但只能使用。
正如你所看到的，Kubernetes的这方面非常复杂和强大，所以看看文档，因为它们解释了和也有很多例子:
服务帐户- https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/
RBAC - https://kubernetes.io/docs/reference/access-authn-authz/rbac/
RBAC资源列表-如何在角色定义中引用所有子资源?
更新
你没有做错什么。这只是你试图使用资源namespace，但Gitlab没有绑定，可以访问这种类型的资源。对于你的ClusterRole，你只是让它访问secrets，但仅此而已。
考虑给ClusterRole更多的权限，将其更改为列出您需要访问的所有资源:
rules:
- apiGroups: [""] # "" indicates the core API group
resources: ["secrets", "namespaces", "pods"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
例如，这将允许访问秘密，命名空间和pod。
作为一种替代方法，你可以将Gitlab的服务帐户绑定到cluster-admin，以直接给它访问所有的权限.
kubectl create clusterrolebinding gitlab-is-now-cluster-admin
--clusterrole=cluster-admin
--serviceaccount=gitlab:default
在这样做之前，请考虑以下事项:
细粒度角色绑定提供更高的安全性，但要求更多努力管理。更广泛的拨款可能会带来不必要的(和)后果(可能会升级)对ServiceAccounts的API访问，但更容易管理。
所以，首先决定哪些资源可以被Gitlab使用，然后创建一个Role/ClusterRole来只访问这些资源(以及你需要的动词)是更安全的方法