Monorepo access token setup tedious

Regarding service tokens:

I understand the principle of least privilege, scoping everything per project and config.

But when using a Monorepo and something like Turborepo or NX, the access token setup and control can become very tedious for the CI/CD pipeline. For CI I would need one access token that has access to all CI or TEST configs, instead of 10+ tokens, when running many services.

Is there a way to share a token between configs, so it would have access to multiple projects+configs?

EDIT:
Ok, it seems the token (alone) clearly identifies environment + config, and only the token is needed to let Doppler CLI know, what secrets to get, which kind of contradicts the suggestion above.
Still, some best practices for Monorepos would be great in the docs.

By the way: This is one of the best and most useful services I have used in the last years. The dashboard UI is also superb!

Hey @blunick and welcome to the Doppler community.

Glad you got this figured out and we’ll get some monorepo docs added soon.

Out of interest, what CI/CD environment are you using?

Hey @ryan-blunden , that’s great.

We use https://semaphoreci.com/ cause they run on quite fast machines.

Nice! I hadn’t heard of them. Will check them out.

Thanks!

I’m also wondering how to go about configuring tokens for CI. I need to be able to access ~ 8 projects and 3 environments per project which means adding 24 different doppler tokens as secrets!

Hi @sambs!

We actually are working on a new feature called Service Accounts that should help a lot in this respect. It will let you generate tokens that have access to multiple projects and configs by creating a “service account” that you can add to projects and configs like normal users to control what they have access to. This feature should be out in the relatively near future, so keep an eye out for it!

Regards,
-Joel

4 Likes

Great news @watsonian, that’s exactly what we need!

Hey @watsonian ! Do you have further details on this feature?

I’d like to know if it’d be possible to use it within github actions (as the OP is asking), like the following (e.g. with DOPPLER_TOKEN_MY_APP a “service account” token having access to three projects) :

name: Example action

on: [push]

jobs:
  my-job:
    runs-on: ubuntu-latest
    steps:
      - name: Install CLI
        uses: dopplerhq/cli-action@v2
      - name: Do something with the CLI
        run: doppler secrets --only-names
        env:
          DOPPLER_TOKEN: ${{ secrets.DOPPLER_TOKEN_MY_APP }}

Since I find the Github integration for an entire organization a bit difficult to use and not easily scalable (every repository need to be added one by one), it’d be easier for us to workaround it by implementing the dopplerhq/cli-action (above example) as a composite/global action (Composite actions + Organization required workflows) with a token that can fetch multiple projects at once. Let me know if there’s a better way to achieve this :v:

Cheers!

PS: I also have an open issue #359 about a similar feature, I’m wondering if the “service account” feature will provide the same possibilities? :thinking:

Hi @Grraahaam!

Yep, it would definitely be possible to use one of these service account tokens in our GitHub Action. All that action does is install our CLI. You then just pass in the DOPPLER_TOKEN environment variable with a valid token (which could be a service account token) and then you can execute CLI commands. Note that you’d need to specify the project and config in those commands since it can no longer be inferred from the token itself. We do also have this action available as well:

Yeah, I can see how that could be easier to setup for sure. One thing to consider is that syncing secrets to GitHub does provide you an amount of insulation from outages or other issues. For example, if there were ephemeral network connectivity issues on GitHub’s side for outbound connections, it wouldn’t impact you if you were reading synced secrets most likely whereas it would if you were making API calls to Doppler for every workflow execution. Inversely, if we had some sort of outage, your actions would all fail until that was fixed. If you were using syncs, then your builds would continue working fine. Just something to consider!

Also, regarding the open issue you have – these service account tokens should solve what you’re after there!

1 Like

Thanks for the insights!

I do understand the “sync” benefits over the “github action” ones, and I’d rather use the “sync” option myself! But until you support Github organization secrets syncs, we need to find a scalable/automated workaround to automatically inject secrets into our newly created repos’ workflows (since we’re a small team, having it done automatically would be awesome)

It seems possible to sync Github organization secrets through their API tho, and you could even automatically import existing Github secrets to a Doppler project as well (they have a LIST/GET endpoint). But there may be some security concerns behind, which I’m not aware of yet. Anyway here’s the mentioned API if ever you guys plan to support it (I’d love it) :


Do you know if it’d be possible to automatically generate service accounts tokens from a config file with doppler setup, like with the doppler.yaml today, or the feature is still in an early stage and the communication is planned for later?

Thanks! :v:

Any update on Service Account availability @watsonian?

Ping - any update?

We are now at the stage where we use personal access token to get secrets.
This is the opposite to secure, but it’s currently the only option unless we split our monorepo (which makes no sense)

@sambs @siggy Our Service Accounts feature is getting close! Baring any major issues, I believe we’re planning on getting it out this quarter still.

@Grraahaam I don’t believe it will be possible to generate service account tokens from a config file like you’re describing.

As an aside, people on this thread might be interested in this CLI change that will be going out in the very near future:

2 Likes

Monorepo setup files are now supported in v3.57.0 of the CLI! So, if you update you can start taking advantage of this now!

Unfortunately, we’re having to roll this change back due to some issues it caused that we didn’t catch initially (notably, it broke interactive invocations of doppler setup). We had a tentative fix ready for it, but decided to rollback instead so we had more time to review things. I’ll post again here when the fixed version is released with support for this.