K
Q

Authentication Issue: GitLab CI/CD Job fails when it runs "kubectl apply -f deployment.yaml"

3/2/2020

I get this error: forbidden: User "system:anonymous" cannot get path "/openapi/v2": No policy matched.

It seems to happen here:

I0302 15:57:33.593662      44 round_trippers.go:423] curl -k -v -XGET  -H "Accept: application/com.github.proto-openapi.spec.v2@v1.0+protobuf" -H "User-Agent: kubectl/v1.17.3 (linux/amd64) kubernetes/06ad960" -H "Authorization: Basic YWRxxxxxxxxxxxxxxxxxxxxxx2lm" 'https://<IP>/openapi/v2?timeout=32s'
I0302 15:57:33.767657      44 round_trippers.go:443] GET https://<IP>/openapi/v2?timeout=32s 403 Forbidden in 173 milliseconds

The user which should be used, as long as I understand it, was created by applying this yaml via kubectl:

apiVersion: v1
kind: Namespace
metadata:  
  name: gitlab-managed-apps
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: gitlab-admin
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: gitlab-admin
  namespace: gitlab-managed-apps

There's also a service account within the GCP project with Kubernetes Engine Developer permissions.

As such, I've no idea why there's still no user defined/associated. I hope you can help me!

-- stefan
gitlab
gitlab-ci
google-cloud-platform
google-kubernetes-engine
kubernetes

Similar Questions

Load agent dynamically in declarative Jenkinsfile
Error: UPGRADE FAILED: failed to create resource: ConfigMap in version "v1" cannot be handled as a ConfigMap
How to configure istio to use external monitoring system (Prometheus and Grafana)
Check existence of nested object in Helm

1 Answer

3/3/2020

After several tries, I found out that I mixed something up with the contexts. I looked at the KUBECONFIG file when I realized the miss-configuration.

The wrong context which was used for the communication with Kubernetes lead to the issue described above.

You can follow the description from this answer to check if you use the right context.

Here's what I did to solve the problem:

  1. I checked the config file:
    • kubectl config view

I noticed that the setting of current-context points to the wrong context!

  1. Then I set the context which was intended to use:
    • kubectl config get-contexts
    • kubectl config set-context NAME
    • kubectl config use-context CONTEXT_NAME

Here you can find a cheatsheet, which I find very helpful.

-- stefan
Source: StackOverflow