-
Notifications
You must be signed in to change notification settings - Fork 130
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
Fails to run on GKE because of permission issue #6
Comments
@avnersorek I do not have access to GKE. I use home brewed k8s clusters. |
@groundnuty |
HI this is my solution to this issue (just an example) -
|
@groundnuty LMK if you want me to open a PR to add some reference from README to this issue. Thanks |
@avnersorek you're more than welcome to create a PR. Shamely in our cluster I just use
as this type of none-security is enough for our needs. I have yet to master RBAC ;-( |
This also fails on a fairly stock AWS EKS cluster for the same reason. @avnersorek 's solution should work, but I'm hesitant to grant access to the Unfortunately, This is what I ended up doing for a Helm chart. Thanks to @avnersorek for most of what I needed to figure this out! 👍 It currently assigns the grants to the
For those that come across this later, granting access to the I ended up making an entirely new tool that separates the Kubernetes API access into it's own isolated server that can run with a properly configured ServiceAccount. The initContainers then need no special permissions: https://github.com/rally25rs/k8s-when-ready |
For anyone coming here, you may create a ServiceAccount with limited permissions. Here's an example of one that only has access to apiVersion: v1
kind: ServiceAccount
metadata:
name: my-service-account
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: my-service-account
rules:
- apiGroups: [""]
resources: ["pods"]
resourceNames: ["pod1", "pod2"]
verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: my-service-account
subjects:
- kind: ServiceAccount
name: my-service-account
roleRef:
kind: Role
name: my-service-account
apiGroup: rbac.authorization.k8s.io Then, simply use the service account in your deployment template spec. |
Two years later there are still no special service accounts for init containers. |
quite similar to the previous ones:
I think as a basic simple solution it's ok to bind a generic role to the namespace |
The container fails on
Error from server (Forbidden): jobs.batch "init-data-job" is forbidden: User "system:serviceaccount:default:default" cannot get jobs.batch in the namespace "default": Unknown user "system:serviceaccount:default:default"
The text was updated successfully, but these errors were encountered: