#Dynamically getting secrets within a module
1 messages ยท Page 1 of 1 (latest)
I keep getting errors like this:
unable to lookup "op://[REDACTED]]/[REDACTED]/CLOUDFLARE_ACCOUNT_ID": Neither `OP_SERVICE_ACCOUNT_TOKEN` is set nor `op` binary is present
I know I can pass secrets as parameters to the function, but I have like 16 secrets that I'd rather not have to pass on every dagger call ๐ฆ
Or is everyone setting up a separate Makefile/Justfile/scripts to actually use dagger?
@river lotus Dagger lacks that convenience, for now. It's because we generally prioritize strong sandboxing (which leads to a safer and more reliable platform) over short-term convenience. Then we try to add layers of convenience on top ๐ Here's the issue for this particular convenience, it's definitely on our radar. https://github.com/dagger/dagger/issues/9584
Also Dagger natively supports recursion. So when you call dag.Secret("op://...") from your module, it's actually correctly querying 1password, just from the context of the module's sandboxed runtime. That doesn't solve your problem, but it's useful to understand how it works under the hood and why we designed it this way.
ohh I see, thanks!
and I promise I searched before asking but between discord and multiple GH issues I was getting confused
No worries, sorry for the confusion
Happy to know it's on the radar - I'm happy to add a Justfile in the meantime to make it easier
with Earthly being shutdown in a few months, I'm much more eager to migrate to dagger
Did you see our joint announcement with Earthly this morning?
One thing that I found weird with lots of secrets is that it adds a lot of time to the withExec span when it seems to just be fetching secrets - it would be nice if there was a separate span when it spends 8 seconds fetching secrets
I also feel like dagger could be a bit more efficient/faster with secret fetching considering that all of these secrets come from a single 1Password item, but (I'm guessing) it's fetching them all individually (possibly with no concurrency?)
One way I found to speed it up is to use op cli myself to retreive secrets instead of dagger's 1Password integration
that brought the withExec span down to 400ms
@river lotus would you mind filing an issue? I think it's either a CLI or engine bug - something is resolved serially instead of concurrently
do you know by any chance if the op CLI fetches the secrets concurrently?
in any case, that's spot on feedback. Thx for brigning it up! will fix shorty ๐
It's very fast so I think so? Although all of my secrets are from a single item in 1P so it might be fetching the one item rather than re-fetching for every secret
make sense that the op CLI optimizes that ๐
cc @fringe venture @tired topaz since you have context on secret providers ๐
@river lotus I assume this is not using OP_SERVICE_ACCOUNT_TOKEN?
There's 2 implementations for op -- when using OP_SERVICE_ACCOUNT_TOKEN it's using the 1Password API, and when not setting it it's using the op binary if present
the CLI invocation is meant for seamless development, but "production" usage should be using the OP_SERVICE_ACCOUNT_TOKEN
@tired topaz implemented caching as well for vault -- perhaps we should do the same for op?
Although the tricky part is that for vault we have no choice to fetch the entire item. Whereas op gives us a way to fetch a single field within an item ...
To support caching we'd have the fetch the whole item rather than just the field (e.g. more than the user requested), which doesn't sound too good security-wise (e.g. you ask for foo/field, and we end up fetching and loading foo/* -- not great)
I tried with both the service account token and the op binary and both were slow
Secrets in dagger are "just in time" (they're loaded as they're accessed), so we don't know in advance which secrets the dag is going to use
I'll give it a try locally
Out of curiosity, why wouldnโt caching work when fetching a single field?
Oh it would. I suspect the slowness compared to using op directly is it fetches all the fields within a secret
you have 8 secrets, coming from the same item, different fields. Correct?
Ohh I see yeah.
Correct
Ok, reproing here
I think if we could do like 10 concurrent fetches it would go pretty fast
I've patched the engine to get some more visibility on op calls
@mental abyss Confirmed that the they get resolved sequentially ...
1 โ [2025-04-18 15:07:03.748368 -0700 PDT m=+2.131914793] OP SECRET PROVIDER Private/dagger test/s1
2 โ [2025-04-18 15:07:04.640784 -0700 PDT m=+3.024454460] OP SECRET PROVIDER Private/dagger test/s2
3 โ [2025-04-18 15:07:05.504448 -0700 PDT m=+3.888232001] OP SECRET PROVIDER Private/dagger test/s3
4 โ [2025-04-18 15:07:06.426638 -0700 PDT m=+4.810536043] OP SECRET PROVIDER Private/dagger test/s4
5 โ [2025-04-18 15:07:07.272362 -0700 PDT m=+5.656358876] OP SECRET PROVIDER Private/dagger test/s5
6 โ [2025-04-18 15:07:08.203619 -0700 PDT m=+6.587719501] OP SECRET PROVIDER Private/dagger test/s6
7 โ [2025-04-18 15:07:09.102311 -0700 PDT m=+7.486504793] OP SECRET PROVIDER Private/dagger test/s7
8 โ [2025-04-18 15:07:10.031499 -0700 PDT m=+8.415782835] OP SECRET PROVIDER Private/dagger test/s8
9 โ [2025-04-18 15:07:10.950931 -0700 PDT m=+9.335299960] OP SECRET PROVIDER Private/dagger test/s9
10 โ [2025-04-18 15:07:11.916055 -0700 PDT m=+10.300507043] OP SECRET PROVIDER Private/dagger test/s10
Looking into it
Also they only get called once, so caching each wouldn't change anything
I think this is what happens -- each secret is loaded just in time. We only fetch the field that was requested, and each op resolve takes a bit of time
Paging Dr @gritty lion -- TLDR: secret attachables get called sequencially in a blocking fashion. I think that's just the way it is with buildkit resolver?
Oh no wait -- maybe it's our own mutex
We're using an RLock here, so theoretically they shouldn't be blocking each other there, unless something else is holding a write lock
Yeah it looks like buildkit is doing it in serial here https://github.com/sipsma/buildkit/blob/03396bcf635a07d4e0ad7b50dab1a28d71f8f132/solver/llbsolver/ops/exec.go#L554-L562
we only lock in AddSecret
thanks!
@gritty lion Follow up to that ... any ill advised reason not to use an errgroup and do that in parallel? and what's the latest with buildkit patches, do we still run a fork?
No looks like switching to errgroup should be an easy fix. Can just open a PR in our fork here: https://github.com/dagger/buildkit
Once we get to porting WithExec dagger native code it'll all be in-house, but for now we're just patching as needed there
yeah we merge our changes to master there
and just cherry-pick from upstream buildkit as needed
LGTM, if you want to test locally against dagger before merging you can just update the go.mod replace for github.com/moby/buildkit to point to your commit
would it work to point to to the local FS with the PR checked out?
bk versions are a little intimidating, it's github.com/moby/buildkit => github.com/dagger/buildkit v0.0.0-20250415011403-6f5903130a80 now
oh no local it won't work because of the sandbox
i'll try go get github.com/dagger/buildkit@<commit>
that's what I do ๐
there's even an unglier hack to use local replaces but you probably don't even want to heart about that
i'll re-try with moby/buildkit rather than dagger/buildkit
dagger/buildkit didn't work
go: downloading github.com/dagger/buildkit v0.0.0-20250418223454-60c160d09b68
go: github.com/dagger/buildkit@60c160d09b6878d933677a671176bc61c5fd893f (v0.0.0-20250418223454-60c160d09b68) requires github.com/dagger/buildkit@v0.0.0-20250418223454-60c160d09b68: parsing go.mod:
module declares its path as: github.com/moby/buildkit
but was required as: github.com/dagger/buildkit
@fringe venture try adding this in the replace github.com/dagger/buildkit v0.0.0-20250418223454-60c160d09b68 and then go mod tidy && go build ./cmd/engine?
the second command failed because i'm on mac ... trying a ./hack/dev to see if it works
building worked locally on linux
so ./hack/dev/should
๐ง โค๏ธ
14 โ [2025-04-18 15:48:41.179835 -0700 PDT m=+3.581065667] OP SECRET PROVIDER Private/dagger test/s10
15 โ [2025-04-18 15:48:41.180266 -0700 PDT m=+3.581496084] OP SECRET PROVIDER Private/dagger test/s1
16 โ [2025-04-18 15:48:41.180318 -0700 PDT m=+3.581548584] OP SECRET PROVIDER Private/dagger test/s6
17 โ [2025-04-18 15:48:41.180373 -0700 PDT m=+3.581603709] OP SECRET PROVIDER Private/dagger test/s3
18 โ [2025-04-18 15:48:41.180443 -0700 PDT m=+3.581673501] OP SECRET PROVIDER Private/dagger test/s5
19 โ [2025-04-18 15:48:41.180498 -0700 PDT m=+3.581728917] OP SECRET PROVIDER Private/dagger test/s2
20 โ [2025-04-18 15:48:41.180542 -0700 PDT m=+3.581772917] OP SECRET PROVIDER Private/dagger test/s7
21 โ [2025-04-18 15:48:41.180609 -0700 PDT m=+3.581839084] OP SECRET PROVIDER Private/dagger test/s4
22 โ [2025-04-18 15:48:41.180901 -0700 PDT m=+3.582131167] OP SECRET PROVIDER Private/dagger test/s8
23 โ [2025-04-18 15:48:41.181006 -0700 PDT m=+3.582236126] OP SECRET PROVIDER Private/dagger test/s9
They're all in parallel now ๐
and the secrets are still there
@gritty lion Ok to merge?
Now should I update dagger doing the same thing or is there a different procedure
?
yes, you need to send a PR to dagger/dagger with that replace bump
that's it
@nocturne adder how did you come up with the first part (2025041822345)?
oh, got it -- did a go get, it failed but it spat out the version in the error messages
yep