[Feature] Actor Identity

[ahmedtd]

For Alpha, we need to give Actors access to OIDC JWTs and SPIFFE certificates issued by substrate. We already have the broker RPCs implemented, but we have the following open items:

• How do we expose the credentials into the Actor (filesystem mounts, metadata server, vsock)?
• Formalize the claims in each credential.
• Make atelet/ateom use the actor credentials for snapshot storage / retrieval.
• (For GCP) Prove out federation of the substrate IDP back to GCP, and demonstrate how it can be used against GCS.

Basic design

The substrate control plane includes a broker API, where a caller can exchange a K8s-layer credential (service account JWT or service account certificate) for a substrate JWT / certificate.

The substrate credential will carry at least the following claims:

• Actor Template Namespace
• Actor Template Name
• Actor ID

These credentials will be federatable, and so should be able to be used against GCS, S3, and other cloud provider services. They could also be used for actor-to-actor authentication, and general actor-to-service authentication.

(GCP-specific) Federation

Both OIDC JWTs and SPIFFE certificates can be federated into GCP IAM using Workload Identity Federation.

While it will not be scalable to create and delete per-actor IAM policies for each actor, it should be possible to use IAM conditions to write a single policy that authorizes every actor to access their own data. For example, "all callers from substrate issuer X have storage/object.admin on GCS bucket Y, as long as the object path starts with actors/${ate.dev/actor-id}".

[EItanya]

This design makes a ton of sense to me. I have a quick question about the broker API you mentioned above.

Do you envision the actors being able to reach the control-plane directly, or the ateom having some sort of metadata service that the actor can access from within it's isolated space.

[ahmedtd]

When we originally wrote the broker, we were still using an "exterior gVisor" model, where we had the actors running directly as pods under a gVisor runtimeclass. In that model, we had the actor workloads directly call the broker and pass their K8s credential.

Now that we are on interior gVisor, I'm leaning towards the default solution being something similar to k8s projected token and podCertificate volumes, so that actor workloads read their credentials from the filesystem. Ateom/atelet would handle fetching the actor tokens/certs, putting them into the actor filesystem, and keeping them refreshed.

However, I know we are also going to need to support a model where an egress proxy injects the credentials.

[EItanya]

Now that we are on interior gVisor, I'm leaning towards the default solution being something similar to k8s projected token and podCertificate volumes, so that actor workloads read their credentials from the filesystem. Ateom/atelet would handle fetching the actor tokens/certs, putting them into the actor filesystem, and keeping them refreshed.

That makes sense to me

However, I know we are also going to need to support a model where an egress proxy injects the credentials.

I view them as slightly different use-cases. The actor identity will allow you to authenticate with services which understand, and or are federated with substrate. However, oftentimes it's more a case of adding long-lived credentials or some such, even if the federated identity is more secure in most cases.

[alexvanboxel]

How do we expose the credentials into the Actor (filesystem mounts, metadata server, vsock)?

What about implementing the SPIFFE Workload API to get the identity of the actor? It serves both JWT and X.509 use cases.