Reputation: 485
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
Reputation: 485
I could do that works!!
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.
sh "helm upgrade --install --namespace jenkins ${HELM_APP_NAME} --set image.tag=${BUILD_NUMBER} ./${HELM_CHART_DIRECTORY}"
Thanks for your time.
Upvotes: 0
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