-
Notifications
You must be signed in to change notification settings - Fork 74
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
Using with Helm #39
Comments
And all your deployment specs can stay the same if they were using Kubernetes Secrets already. |
@florisvdg thanks for the help. I have completed steps 1, 2, 3.
When trying to store the CRD though, I am getting the following error::
The contents of
|
@florisvdg found my problem, needed a few more flags when doing the Helm install:
I was able to store the secret using the above
I do see the
|
@nodesocket When you set up using the helm chart did you create a cluster role, service account, and rolebinding for the operator? |
@jillianwilson thanks for the reply. Doesn't the official helm chart create the cluster role, service account, and role binding? If not, why not? Also, I must have missed that in the documentation. Can you point me to it? |
Yes, it does, but you have to explicitly enable it: operator:
create: true
serviceAccount:
create: true
roleBinding:
create: true
clusterRole:
create: true In the next release, we'll make it create the RBAC resources by default so you'll only have to add |
@florisvdg ok thanks. Any idea when the next release is due to come out with RBAC resources created by default? Also, can I use |
And about the secure notes, the Kubernetes operator treats them like any other 1Password item. The Kubernetes Secret field where the note contents will get mapped to is |
I am currently using standard Helm and a template like:
Then the deployment simply does:
Finally, in the
values.yaml
we specify the secrets like:How would migrating to 1Password-operator in our Kubernetes cluster work?
The text was updated successfully, but these errors were encountered: