Add ActorID to the injected actor's process

[dberkov]

In some cases, it might be useful for the actor to know its own ID. Currently, the only way to determine this is by stripping the incoming request from atenet and extracting the ID from the host name.

Might be expose actor's ID via environment variable or a file on the rootfs?

[bowei]

Env var maybe impossible for vm.

We may consider seeing this information from a metadata server on a link local address as well. This could then be used to write a file etc for ease of use.

[juli4n]

I think we need to look at this comprehensively. We need late-binding of configuration within an actor, and it would be nice if we have a single way of doing it. We will need the analogous of projected volumes, at very least config maps, secrets and some downward API (e.g. actor id), but the list will grow (e.g. certificates and OIDC tokens for for actor identity).

[dberkov]

I totally agree, we need a generic way to support multiple configurations and we need to build it over time. The #184 is a good start of it. We might need refactor it soon to support additional fields.

+1 for Bowei Du (@bowei) 's suggestion, env variable is not a good solution, we need store in a file.

[fkautz]

Would it make sense for me to refactor #184 to be a read only directory and mount it in, rather than mounting the file? Happy to do so.

[bowei]

Echoing Julian's comment, we need to evaluate the generic mechanism to be used to project generic information into the Actor. I think the current lead thought is a projected volume, but a couple of things need to be worked through:

1. Compatibility across the various sandbox runtimes (e.g. uVM, gVisor)
2. Some basic stuff on how things will be laid out. For example, where the files will go, what daemon to run.
3. Some consideration of the gotchas. Any service that goes into the guest could be abused (like sending it a bunch of requests), so the solution should take that into account.

[fkautz]

Update: rather than refactoring later, I went ahead and changed #184 to mount a read-only per-actor directory at /run/ate, with the ID in the file actor-id inside it. Since the mount shape is now a directory, future late-bound data (more downward-API fields, config, eventually certs/tokens per Julian Gutierrez Oschmann (@juli4n)'s list) can land as sibling files without breaking the contract.

To be clear about scope: #184 is not the generic projection mechanism Bowei Du (@bowei) describes. There is no daemon, no metadata service, and nothing refreshed at runtime; atelet just regenerates the directory contents on every resume. The three design questions (runtime compatibility, layout, abuse surface of anything guest-facing) stay open here.

[fkautz]

So a question... would it make sense to perhaps have two ways to communicate?

• /run/ate/ for storing read-only, slowly changing data. Super easy for an app to use: plain open()/read(), no client library.
• /run/ate/api.sock (AF_UNIX) for anything dynamic, parameterized, or bi-directional. This should be trivial to implement in gVisor (it can ride the existing mount as a host UDS passthrough) and should also work with most hypervisors.

For the socket on VM runtimes, the path would probably need to be:

AF_UNIX (/run/ate/api.sock) -> guest agent -> AF_VSOCK -> hypervisor/VMM -> host -> atelet

On gVisor there is no agent or vsock hop; the workload's connect goes through the gofer straight to a host socket owned by atelet. The guest agent can be a dumb byte-splicing proxy, with the actual protocol end-to-end between the workload and atelet.