Jose Amadeo Diaz Diaz
Jose Amadeo Diaz Diaz

Reputation: 485

Deploying helm chart in Kubernetes with Jenkins

https://www.jenkins.io/doc/book/installing/kubernetes/#install-jenkins-with-helm-v3

kubectl apply -f jenkins-sa.yaml

https://github.com/joedayz/node-k8s-cicd/blob/main/Jenkinsfile

But When I execute my pipeline I got it error:

Release "node-app-chart" does not exist. Installing it now.

Error: rendered manifests contain a resource that already exists. Unable to continue with install: could not get information about the resource ServiceAccount "node-app-chart" in namespace "jenkins": serviceaccounts "node-app-chart" is forbidden: User "system:serviceaccount:jenkins:jenkins" cannot get resource "serviceaccounts" in API group "" in the namespace "jenkins"

script returned exit code 1

I am using minikube, helm v3, docker hub, github. The repo is public.

Any idea?

Thanks in advance.

Upvotes: 0

Views: 1078

Answers (2)

Jose Amadeo Diaz Diaz
Jose Amadeo Diaz Diaz

Reputation: 485

I could do that works!!

  1. In values.yamls

serviceAccount: # Specifies whether a service account should be created create: false

No create service account. Because it's trying to create a service account with the name of the chart.

  1. In jenkinsfile change the command to:

sh "helm upgrade --install --namespace jenkins ${HELM_APP_NAME} --set image.tag=${BUILD_NUMBER} ./${HELM_CHART_DIRECTORY}"

Thanks for your time.

Upvotes: 0

SYN
SYN

Reputation: 5041

"could not get information" ... "permission denied". Your error message suggests your jenkins ServiceAccount does not have privileges getting resources within its own namespace.

And given the name of the ServiceAccount jenkins tries to get is some "node-app-something", we should probably assume that beyond getting objects, Jenkins would eventually need to create them as well.

Anyway, you would want to create a RoleBinding, in your jenkins namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: jenkins-admin
  namespace: jenkins 
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: admin
subjects:
- namespace: webapps 
  kind: ServiceAccount
  name: jenkins

Using the admin ClusterRole is probably not the best pick. Still, if you are managing ServiceAccounts for your app, your pipeline may eventually create RoleBindings as well granting that ServiceAccount with privileges over your cluster. If you need to create RBAC configurations, admin would work for sure.

If you do not want Jenkins to manage privileges delegations within its own namespace, you may instead use the edit ClusterRole.

If you do not want Jenkins to create objects within its own namespace, you could go with the view ClusterRole.

Note that Jenkins may need edit privileges, assuming you did setup Jenkins Kubernetes cluster integration (and dynamic agents provisioning, running your Pipelines)

Going with admin: maybe you should consider deploying your applications into a separate namespace: don't grant Jenkins with admin privileges over its own namespace, rather grant those privileges over whichever namespace should host your jenkins-managed applications.

Upvotes: 0

Related Questions