CUE SDK - Current state + potential futures 🔮

[jlongtine]

I've gotten a good chunk of work done on a port of the v0.2/Europa API to the v0.3+/multi-language engine.

I'd like to:

• speak to the current progress on that
• write about the parts of the API that aren't currently working (largely because of features that aren't yet implemented in the v0.3+ engine)
• get feedback on the interest level in continued work on this port
• get feedback on the interest in potential future CUE SDKs -- what I've been calling a GraphQL-native CUE SDK (think generated CUE not dissimilar to the Go/Python/Typescript SDKs

v0.2/Europa API Port Progress

Much of the context is in #3121.

That said, the current major blockers are

• Secure secrets support in the current engine is only available through environment variables, and a few (resolvable) architectural issues make it impossible to support core.#NewSecret, core.#DecodeSecret, core.#TrimSecret, client.commands without secrets getting into the engine cache (and thus on disk in an unencrypted form).
• client.network: recent releases of the engine should unblock this
• core.#Exec always: true is not implemented
• Authorization for core.#GitPull, core.#Push, core.#Pull are not implemented
• core.#Dockerfile is only partially implemented

There are a few other small things missing, which you can see on #3121, and I'm planning on adding to engine v0.3 soon.

I'd like to understand the current interest in this port being finished.

CUE Futures 🔮

This one is substantially fuzzier for me.

The general idea of a CUE SDK for the GraphQL API (generated similarly to our other SDKs) makes sense to me.

I'm uncertain about the design, and haven't yet given it much thought.

Some things are straightforward, like generating CUE structs for various GraphQL scalar data types.

type Container {
  id: ContainerID!
  platform: Platform!
  rootfs: Directory!
  user: String
  workdir: String
  envVariables: [EnvVariable!]!
  entrypoint: [String!]
  defaultArgs: [String!]
  mounts: [String!]!
  exitCode: Int
  stdout: String
  stderr: String
}

type EnvVariable {
  name: String!
  value: String!
}

Can become:

#ContainerID: string
#Container: {
  id: #ContainerID
  user: string
  workdir: string
  envVariables: #EnvVariable
  entrypoint: [...string]
  defaultArgs: [...string]
  mounts: [...string]
  exitCode: Int
  stdout: string
  stderr: string
}

#EnvVariable: {
  name: string
  value: string
}

But I'm not sure how we could design fields with arguments (i.e. "functions").

type Container {
  from(address: String!): Container!
  ...
}

I'd love to hear ideas, if anyone has any!

[Alvise88]

Do you consider something like this ?

#Container:  #From | #WithExec | #WithDirectory | #WithEnvVariable

#From: {
    address: string
}

#WithExec: {
    on: #Container
    args: [...string]
    stdout: string
    stderr: string
}

#WithDirectory: {
    on: #Container
    path: string
}

#WithEnvVariable: {
    on: #Container
    name: string
    value: string
}

homepage: #WithExec & {
    args: ["curl", "https://dagger.io/"]

    on: #WithExec & {
        args: ["apk", "add", "curl"]

        on: #From & {
            address: "alpine:3.16"
        }
    }
}

[jlongtine]

There are some interesting ideas here!

I'd need to experiment with a few things to make sure this would work. cue/tools/flow tasks are a bit tricky sometimes... but I think there's a way to define the tasks so that this structure would work.

There are some rumblings in the CUE community around a cleaner definition of function calls... and that could help with this. But... it's also only in the design stage, so not ready for deeper experimentation.

I'll think on it some more, and see what other possibilities come to mind!

[shykes]

I've gotten a good chunk of work done on a port of the v0.2/Europa API to the v0.3+/multi-language engine.

Very nice! It looks like we are close to being able to merge this, which would be fantastic.

That said, the current major blockers are

• Secure secrets support in the current engine is only available through environment variables, and a few (resolvable) architectural issues make it impossible to support [...]

core.#NewSecret

Isn't that supported via File { secret }?

Example.

core.#DecodeSecret, core.#TrimSecret

Have we exhausted all options there? My first reaction is "this should be doable in userland with the existing API", but I might be wrong.

client.commands without secrets getting into the engine cache (and thus on disk in an unencrypted form).

Right, I remember you explaining this one to me. We had a great hack/workaround, but it got ruined as a side effect of the Go SDK switching to using the session helper, because that prevented you from dynamically setting env variables

What are our options for working around this one?

• core.#Exec always: true is not implemented

We need this in the API anyway, we could prioritize it to unblock you. (cc @vito @sipsma @aluzzardi)

• Authorization for core.#GitPull, core.#Push, core.#Pull are not implemented

Same, we need this in API anyway.

• core.#Dockerfile is only partially implemented

I'm guessing the missing features are also things we would want outside of the CUE SDK? Registry auth etc?

There are a few other small things missing, which you can see on #3121, and I'm planning on adding to engine v0.3 soon.

This is great.

I'd like to understand the current interest in this port being finished.

Very high for me :) We seem to be very close, and switching to engine 0.3 will allow us to stop maintaining the 0.2 engine without breaking CUE users. It doesn't resolve the question of what to do next for the CUE SDK. But it does make the current status quo less expensive to maintain, which buys us time to decide what comes next.

My strong preference would be to ship this ASAP, unless the engineering effort is too great, or we can't reduce migration pain to an acceptable level.

[vito]

Isn't that supported via File { secret }?

If you use File { secret } to get a SecretID but you accessed that file by running a command with secure tokens (like vault read), the SecretID would contain those secrets somewhere.

Similarly if you use WithNewFile to create a file with secret contents, the SecretID itself contains the secret value in plaintext. (Obfuscated behind base64, but still unsafe.)

So we need a way to bootstrap secrets into Dagger and either use them directly or allow them to be used to fetch other secrets using commands like above, but resulting in a "clean" SecretID.

We need this in the API anyway, we could prioritize it to unblock you. (cc @vito @sipsma @aluzzardi)

Opened #4118 for this - I need it too!

[shykes]

My strong preference would be to ship this ASAP, unless the engineering effort is too great, or we can't reduce migration pain to an acceptable level.

After discussing this live with @jlongtine today, I have changed my perspective. It would be great to be able to merge this, but we shouldn't force a merge that introduces security regressions or painful breaking changes.

I do think it's useful to use these requirements as a guide to prioritize work: some of these issues are badly needed regardless of CUE. So if we decide not to merge, we should make sure to keep the priorities.

So we need a way to bootstrap secrets into Dagger and either use them directly or allow them to be used to fetch other secrets using commands like above, but resulting in a "clean" SecretID.

Maybe we should bite the bullet and start seriously discussing the idea of swappable secrets providers? As discussed previously with @aluzzardi @kpenfound and others.

[ttnesby]

Hi, not sure whether this is useful for you.

I'm investing use of cue & dagger in order to be more Infrastructure-as-Configuration versus code. In that context, I created a tiny container registry solution with cue + dagger-cue. In GHA context federation/OIDC is used.

- name: azure login by federation
  uses: azure/login@v1
  with:
      client-id: ${{ env.clientIdU }}
      subscription-id: ${{ env.subscriptionIdU }}
      tenant-id: ${{ env.tenantIdU }}
      enable-AzPSSession: false # no Az modules in use

Thus, azure operations are straight forward. When pushing a new image to the cont. reg., using docker.#Push, an access token is required.

// - start - prepare docker login enabling for azure container registry
creg: {
	_r: #invokeCmd & {							
		#script: "az acr login --name \(crname.value) --subscription \(g.#subscriptionId[tenant]) --out yaml --expose-token --only-show-errors > \(g.#rf)"
	}

	_d: yaml.Unmarshal(_r.result)

	loginServer: _d.loginServer
	accessToken: _d.accessToken
}

cregTokenAsFile: core.#WriteFile & {
	input: dagger.#Scratch
	path: _cregFile
	contents: creg.accessToken
}

// !NB! stays in cache
cregTokenAsSecret: core.#NewSecret & {
	input: cregTokenAsFile.output
	path:  _cregFile
}
// - end

// - build image
build: docker.#Dockerfile & {
	source: client.filesystem.".".read.contents
	dockerfile: path: "/dockerFiles/DockerFile.\(dfpf)"
}

// - push image to container registry :v<datetime>
pushVersion: docker.#Push & {
	dest: "\(creg.loginServer)/azbicue:v\(tag.value)"
	auth: {
		// when access token is used, independent of user type user | servicePrincipal
		username: "00000000-0000-0000-0000-000000000000"
		secret: cregTokenAsSecret.output
	}
	image: build.output
}

A more direct injection of the access token as secret would be appreciated!

[elebeaup]

I just saw that the PR #3565 is closed. Why ? The CUE SDK port to dagger engine 0.3 is cancelled ?

[shykes]

It is not canceled, but it is stalled because of difficulty in reaching full compatibility with the current API. There are some tradeoffs to be made, which require community input. In the meantime @jlongtine is working on other things.

I reopened the PR to avoid confusion.