How to configure a "master token secret"

[jhoelzel]

Hey guys, First of all thank you for the operator, we use it constantly.

Now there has come a point where we are spending more time deploying "token secrets" into the cluster than anything esle, which is especially true if you do feature deployments with kubernetes.

Is there a simple way to deploy a "token secret" with multiple DOPPLER tokens inside and use that to create other secrets?

Usercase:

1) Have a project that contains all the doppler tokens for the different configurations you deploy in kubernetes. At this point im deploying around 10 token secrets and its getting kumbersome to deploy them by hand. 2) deploy these tokens into the cluster using doppler 3) Use the deployed secret of that operation to feed other doppler configurations inside the cluster.

basically im looking for this:

apiVersion: secrets.doppler.com/v1alpha1
kind: DopplerSecret
metadata:
  name: dopplersecret-backups
  namespace: doppler-operator-system
spec:
  host: https://api.doppler.com
  managedSecret:
    name: dopplersecret-staging-postgres
    namespace: postgres-staging
    type: Opaque
  resyncSeconds: 60
  tokenSecret:
    name: doppler-cluster-tokens
    **KEY**: token-backups
  verifyTLS: true

But maybe there is a better way which i simply cant see?

thanks

[watsonian]

@jhoelzel The recommended way to accomplish this would be to use Service Accounts. You can give the SA access to whichever configs you're managing in Kubernetes and then a Service Account Token for it will have access to all those configs. You would then use that one token in all your DopplerSecret CRDs and just reference the project and config name like this:

apiVersion: secrets.doppler.com/v1alpha1
kind: DopplerSecret
metadata:
  name: dopplersecret-test
  namespace: doppler-operator-system
spec:
  tokenSecret:
    name: doppler-token-secret
  project: your-project-name-here
  config: your-config-name-here
  managedSecret:
    name: doppler-test-secret
    namespace: default

That said, Service Accounts are only available on the Team plan or higher. Is that a potential option for you?

[jhoelzel]

Thank you for your answer but that only gives acces to all projects at the same time right?

There is no way to create for instance a "staging" and a "production" token where i want to keep the secrets apart fort security reasons, if i am not mistaken?

thanks in advance

[watsonian]

@jhoelzel Correct. There's no way to provide access to a specific subset of environments on all projects automatically. You can still accomplish that, but you'd need to do it per-project manually. You can automate that via our API though. You can manage it via Terraform as well by using project_member_group and project_member_service_account.

[jhoelzel]

ok thank you for this information, i understand and will work around this.

For the future "secretKeyRef" would still be a nice feature for the tokensecret. In clusters where compliance is needed, i really have to separate production from everything else and that will be the easy way to do it =)

[jhoelzel]

So i have just finished my prototype for this and summing up it would be much easier to implement "secretKeyRef" on your side than for us to have to maintain what bascially is an operator by itself =)

So for christmas, we hope that our feature-request can make it on the list for sometime next year!

Cheers and thank you for creating doppler

[alex-linx]

Hi, we encountered a similar use case that we needed. We implemented a custom solution, to ensure that each deployment got access to just one doppler project.

Basically, we created a doppler project name doppler-tokens, where we would store service tokens for individual projects. So for example if you have project-a and project-b, we would create inside the doppler-tokens project two secrets named PROJECT_A and PROJECT_B and the values would be service tokens for the respective project and config.

We then used external secrets operator to convert each individual key from doppler-tokens into a separate kubernetes secret with a name matching the project name. We then create the doppler secret CRD pointing to the respective secret. We packaged the whole thing as a helm chart, where we just need to specify the name of the doppler project and the config, and it creates the DopplerSecret CRD automatically.

The only thing we need to do, is when we need to add a new doppler project to be used in the cluster, we need to create a service token for it and store it inside of the doppler-tokens project. This we automated using a simple script using doppler CLI.

Ideally we'd like for this functionality to be available out of the box in the doppler kubernetes operator