-
-
Notifications
You must be signed in to change notification settings - Fork 615
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Portainer service account not found #17090
Comments
Even if we update the name of the SA it won't work at least on TN Scale Portainer can only work correctly when it is deployed in the Given that helm users can change the SA name, this is low prio. |
Thank you for the quick answer. What if we could change the config of portainer to assume the SA with name ‘portainer’ instead? I just could’t find the option for this… also, this name is in the common chart? Or can we add it just for portainer chart? I can try to make it work and send a PR if it’s welcome. thank you! |
As the linked comment above says, its all hardcoded currently. The name is in the portainer chart. But with the current design of the naming generation on the common, it would need a "hack". But backtracking a bit. That being said, portainer's examples seem to suggest to use the built-in charts/charts/stable/portainer/values.yaml Lines 27 to 34 in 0686815
Which is tied to the service account. So unless we miss some specific setting, I'm not sure what we should do. And I don't think start changing naming's around is a good idea, unless first the issue is pinpointed. |
Ok, I can investigate first and see what change makes it work. Looking in the source code of portainer, it seems indeed hardcoded, but then... why is it configurable in their helm chart? https://github.com/portainer/portainer/blob/067a7d148f2a71796420e9a5026d8d876a3fb745/api/kubernetes/cli/naming.go#L9-L12 if they would allow those to be configurable via CLI, we could override them, right? What other options do we have? |
As a workaround, I deployed this via fluxcd to my (k3s / TN Scale) cluster and everything works now, including the shell functionality, even tho portainer is deployed as Truecharts App. apiVersion: v1
kind: Namespace
metadata:
name: portainer
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: portainer-sa-clusteradmin
namespace: portainer
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: portainer-crb-clusteradmin
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: portainer-sa-clusteradmin
namespace: portainer
--- |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in two weeks if no further activity occurs. Thank you for your contributions. |
This issue has been automatically closed due to inactivity. Please re-open if this still requires investigation. |
App Name
Portainer
Operating System
TrueNAS SCALE 23.10.1
App Version
2.19.4
Application Events
Application Logs
Application Configuration
Main Ingress
Enable Ingress
Integrations
Traefik
enabled
certManager
enabled (and working)
Describe the bug
Portainer has a built-in functionality for kubectl shell - in browser. This uses websockets to connect.
With the current app/chart version it does not work, it opens and then closes immediately.
I investigated and found out what the error is:
It seems that the configuration of portainer expects this name as serviceaccount name, see also their agent chart installation and oficial chart configuration for
serviceAccount.name
.Can we rename the serviceaccount of the chart to match with what portainer expects or make it configurable?
Thank you!
R
To Reproduce
Open portainer and click on local k8s cluster and then on
>_ kubectl shell
Expected Behavior
Shell works and stays connected on screen.
Screenshots
Additional Context
I thought it's a problem with the websockets headers in traefik, but the same behaviour happens when accessing portainer through the pod app port, so it's unrelated.
I've read and agree with the following
The text was updated successfully, but these errors were encountered: