-
Notifications
You must be signed in to change notification settings - Fork 676
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
Restricted Installation instructions incomplete/broken #7747
Comments
I'm not sure I understand. Could you share the exact steps to reproduce the issue?
There is no ClusterRoleBinding because > k get role -A | grep elastic
elastic-system elastic-operator 2024-05-14T12:45:21Z
namespace-a elastic-operator 2024-05-14T12:45:20Z
namespace-b elastic-operator 2024-05-14T12:45:20Z |
Here's a bit of psudocode as each cluster is a little different. but should give you the general idea. if not, please let me know and I can try and make an even more concrete example. kubeadm kubeconfig user --client-name=foo > foo.kubeconfig
kubectl create namespace foo
kubectl create rolebinding admin -n foo --clusterrole=admin --user foo
export KUBECONFIG=foo.kubeconfig
helm upgrade --install --version 2.12.1 -n foo eck-operator eck-operator \
--set managedNamespaces=foo \
--set installCRDs=false \
--set createClusterScopedResources=false \
--set webhook.enabled=false \
--set config.validateStorageClass=false \
--repo https://helm.elastic.co |
Bug Report
What did you do?
Followed the instructions here:
https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-install-helm.html#k8s-install-helm-restricted
What did you expect to see?
They work
What did you see instead? Under which circumstances?
The operator chart couldn't be installed as a user with a rolebinding of admin in their namespace.
Two problems exist.
There isnt the ClusterRoles for elastic-operator-edit and elastic-operator-view by the process. I manually rendered them from the chart and loaded them in.
Even then, the admin user in the namespace didn't have enough permissions:
The SubjectAccessReview one is more sensitive then the rest. Is it really needed?
Environment
ECK version:
2.12.1
Kubernetes information:
The text was updated successfully, but these errors were encountered: