Skip to content
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

Support only one secret with Aiven token #744

Open
alexgo84 opened this issue Jun 4, 2024 · 4 comments
Open

Support only one secret with Aiven token #744

alexgo84 opened this issue Jun 4, 2024 · 4 comments

Comments

@alexgo84
Copy link

alexgo84 commented Jun 4, 2024

While integrating Aiven operator, I see the operator is expecting to find the Aiven token in a secret that would always be on the namespace of the managed resource.

If in my cluster I've many (hundreds or thousands) of namespaces with resources managed by aiven-operator, it seems redundant to set the same secret with the same token on each one of them. Might also become difficult to manage when the token needs to be changed.

Is there a way to set the secret with token in one place only?
If not, are there plans to implement this?

@alexgo84
Copy link
Author

alexgo84 commented Jun 4, 2024

Related line of code for reference:

if err := c.Get(ctx, types.NamespacedName{Name: auth.Name, Namespace: req.Namespace}, clientAuthSecret); err != nil {

@alexgo84 alexgo84 changed the title Have only one secret with Aiven token on aiven-operator namespace Have only one secret with Aiven token Jun 4, 2024
@alexgo84 alexgo84 changed the title Have only one secret with Aiven token Support only one secret with Aiven token Jun 4, 2024
@rriski
Copy link
Contributor

rriski commented Jun 7, 2024

Hello @alexgo84 and thanks for bringing this up. I can see how the current way of providing the secret via authSecretRef is not very flexible when it comes to managing resources across multiple namespaces. Like you said, currently the secret needs to be configured in each namespace. Given the vast amount of namespaces you have, do you already have a way to configure secrets across namespaces (e.g. https://clustersecret.io/)?

If so, or if it would be acceptable for you to install another operator to handle cluster secrets I think we could extend authSecretRef to support CRD secrets:

apiVersion: aiven.io/v1alpha1
kind: Clickhouse
metadata:
  name: my-clickhouse
spec:
  authSecretRef:
    kind: ClusterSecret # <-- This is new
    name: aiven-token
    key: token

Let me know if this would work for you.

@alexgo84
Copy link
Author

alexgo84 commented Jun 7, 2024

Thanks for the response @rriski .
I believe we could support cluster secret, but really the most straightforward way would be to put one secret on the namespace of aiven-operator. For example, it is possible to define the following optional secret in the aiven-operator deployment manifest:

  - name: AIVEN_TOKEN
    valueFrom:
      secretKeyRef:
        name: aiven-credentials
        key: token
        optional: true

Then, if the secret is present the credentials in the secret will be used (while it'd possible to override them with the now optional authSecretRef).

In other words - if authSecretRef is not provided, aiven-operator can try to fallback on AIVEN_TOKEN environment variable.

@mortenlj
Copy link
Contributor

A solution for this is already implemented:

#183
https://github.com/aiven/aiven-charts/blob/737cb46bbc62c2537254bc753687059f6db685a7/charts/aiven-operator/values.yaml#L13

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants