Error from server (Forbidden): error when retrieving current configuration of: Resource: “apps/v1, Resource=deployments”,

Question

I integrate the existing kubernetes cluster to the gitlab instance (omnibus). I get the below error in the deployment stage of CI/CD pipeline:

Error from server (Forbidden): error when retrieving current configuration of:
 Resource: "apps/v1, Resource=deployments", GroupVersionKind: "apps/v1, Kind=Deployment"
 Name: "test-deployment", Namespace: "default"
 Object: &{map["apiVersion":"apps/v1" "kind":"Deployment" "metadata":map["annotations":map["kubectl.kubernetes.io/last-applied-configuration":""] "name":"test-deployment" "namespace":"default"] "spec":map["replicas":'\x01' "selector":map["matchLabels":map["app":"test"]] "template":map["metadata":map["labels":map["app":"test"]] "spec":map["containers":[map["env":[map["name":"OHH_COMMON_REDEPLOY" "value":"Sun Feb  9 13:55:45 +0330 2020"]] "image":"192.168.10.6:5000/majid/hello-world:v0.01" "name":"test" "ports":[map["containerPort":'P']]]]]]]]}
 from server for: "deployment.yaml": deployments.apps "test-deployment" is forbidden: User "system:serviceaccount:kubetest-2-bina:kubetest-2-bina-service-account" cannot get resource "deployments" in API group "apps" in the namespace "default"
 ERROR: Job failed: exit status 1

There is my .gitlab-ci.yaml file:

deploy:
  image:
    name: lachlanevenson/k8s-kubectl:latest 
    entrypoint: ["/bin/sh", "-c"]
  stage: deploy
  environment:
    name: bina
    url: https://192.168.x.x
  only:
    - master
  script:
    - kubectl version
    - sed -ie "s/THIS_WILL_BE_REPLACED/$(date)/g" deployment.yaml
    - kubectl apply -f deployment.yaml --namespace=default

The deployment file look like this:

apiVersion: apps/v1 
kind: Deployment
metadata:
  name: test-deployment
spec:
  selector:
    matchLabels:
      app: test
  replicas: 1
  template:
    metadata:
      labels:
        app: test
    spec:
      imagePullSecrets:
      - name: regcred
      containers:
      - name: test
        image: 192.168.10.6:5000/majid/hello-world:v0.01
        ports:
        - containerPort: 80
        env:
        - name: OHH_COMMON_REDEPLOY
          value: THIS_WILL_BE_REPLACED

I also create ServiceAccount and ClusterRoleBinding:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: gitlab-admin
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: gitlab-admin
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: gitlab-admin
  namespace: kube-system

clusterRole definition:

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

How can I resolve this issue?

Answer 1

Going from this, your ClusterRole isn't configured to allow access to deployments, and the ClusterRole you've listed isn't properly bound to your service account. You could configure it with something like I did below as a troubleshooting measure/to make sure you're able to properly configure permissions and rule out an issue with the serviceaccount's role bindings.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: gitlab-admin
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: gitlab-admin-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: deployment-reader
subjects:
- kind: ServiceAccount
  name: gitlab-admin
  namespace: kube-system

A new ClusterRole

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: deployment-reader
rules:
- apiGroups: ["extensions", "apps"]
  resources: ["deployments"]
  verbs: ["get", "watch", "list"]

Then to check to make sure the service account can properly access the resource in the default namespace you can check with the following command

kubectl get deployments --as system:serviceaccount:kube-system:gitlab-admin -n default

Answer 2

It is possible to get rid of this problem by uncheck the gitlab-managed cluster checkbox.