Dagger as a 'walled garden'

[zealous meadow]

Couple of questions before next week relating to Dagger as a bit of a 'walled garden' which I think may be of interest, particularly to enterprise users:

1. Can the Dagger engine differentiate between queries made to it that originated from dagger call vs dagger query/dagger run/dagger anything else? If so, could it be configured to disable anything other than dagger call?

2. Could there be an option to whitelist certain domains? e.g. Dagger engine configuration that allows modules and dependencies from company.gitlab.com but errors if a module or dependency is from anywhere else.

Context: I think an option to have Dagger restricted to approved sources only would be well-received. Appreciate this can be (and is usually) done outside of Dagger, but if these would be small changes that can get security teams onside that might be an easy win.

[empty coral]

1. Can the Dagger engine differentiate between queries made to it that originated from dagger call vs dagger query/dagger run/dagger anything else? If so, could it be configured to disable anything other than dagger call?
   All of those ultimately end up as clients submitting graphql queries to the engine underneath the hood, so currently no the engine can't distinguish them. I could imagine ways of perhaps distinguishing them (include a header or similar in the requests that indicate the origin), but curious what the use case would be for this type of restriction.

2. Could there be an option to whitelist certain domains? e.g. Dagger engine configuration that allows modules and dependencies from company.gitlab.com but errors if a module or dependency is from anywhere else.
   Yeah that is something we likely will want to tackle someday, and there's even some features in the low-level buildkit interface we use that would support it, but we have not gotten there yet. There's an issue for this here https://github.com/dagger/dagger/issues/4679

[zealous meadow]

The use case is tied to the source policy question, but I may be unaware of how that'd be applied. It would seem that even with a whitelist of module/dependency sources that a user could at least partially bypass that with queries to the engine, no module/dependency being called in that case?

If an engine can be configured to only accept dagger call and only modules (and dependencies) from approved sources I think there'd be a lot of happy security teams

[haughty dew]

@zealous meadow If you're interested in building something like this yourself - I would note that dependencies and modules installed with dagger install are recorded in dagger.json and that it's not super hard to write a program that keeps track of the hash of this file, along with flagging sources that don't fall in a pre-approved list.

For the dagger Go SDK (not sure how it translates to other SDKs) you can simply regenerate the dagger.gen.go file and other internal files on each CI run after validating that dagger.json is acceptable. I think dagger develop and other commands will do this for you.

I've attached a first draft of this.

I suspect there's variation in the sources format that I don't understand (in my first month with Dagger) but I like this idea in general

Aside: AI is really good at writing one-off tools like this very fast.

@empty coral I saw your re-open and comment on the GH issue. If an approach like the above that's more tailored to the specific structure of Dagger and Daggerverse deps sounds interesting to you or the team I'd be happy to contribute in this way. I know a lot less about the buildkit side of things