Skip to content

Configure egress access for golden snapshot preparation #2358

Open

Description

@EItanya

Golden preparation may need network access that the actors created from its snapshot should never receive. For example, an RL environment might fetch repositories and datasets during preparation, then run many actors with those files already available and no external network access. Keeping preparation permissions separate from runtime permissions makes that possible.

The golden is a controller-managed actor with its own identity. Since the template already describes how to prepare the golden snapshot, it is also the natural place to declare the network access that preparation requires:

goldenEgressPolicy:
  rules:
    - https:
        hostnames: [assets.example.com]

With goldenEgressPolicy, the controller creates the golden actor and its policy atomically, before initialization starts. A separate policy request would require the caller to discover the internal actor and coordinate with its startup. Declaring the policy on the template handles that ordering within the component that already owns it.

I think this is the simplest API for this requirement because it adds one optional field and reuses the existing egress rules, validation, defaults, and enforcement. Actors restored from the snapshot receive their own identities and start without an egress policy, so preparation permissions do not become implicit runtime permissions.

Requiring a full EgressPolicy would also require metadata that the controller already knows how to generate.

Related to #1324 but mostly complementary. Implementation: #2159.

Activity

  1. thockin commented on Oct 9, 2026

    @thockin
    Collaborator

    I agree with the problem statement - it's the same as "init" containers.

    Embedding it into ActorTemplate is sort of ugly, but... I mean, there's a reason we didn't embed it in Actor but that mostly has to do with scale. I don't think we anticipate having the same cardinality of templates as actors, so scale is probably less of a concern. Also, we don't update templates the way we update actors, so size matters less, again.

    So I could probably hold my nose at this. I don't love duplicating the exact schema in 2 places but I guess it is better than trying to do Go embedding and so forth.

    Questions:

    I assume that an actor derived from this template DOES NOT get that policy in any way?

    When we fork an actor from a tag -- do we copy the egress policy? I think not, right?

    Assume an Actor is spawn from a golden. It gets the results of whatever downloads the golden did. Later that actor is upgraded to a new OCI image or something - does it need to re-run the "init" phase? Or is it REQUIRED that the golden save data ONLY to durDir. Is there any part of an actor's lifecycle that means it has to re-run init?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

area/networkarea/securitySecurity related issue/prkind/featureAn enhancement / feature request or implementation

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions