Right now and in the near future, we will have the following credential use cases:
- ateom/atunnel use an actor-scoped certificate to connect to the egress gateway
- The egress gateway can inject an actor JWT into an outbound request.
- (Potential) The egress gateway can use an actor SPIFFE certificate for an outbound request
- (Potential) SystemInfoVolumes can provide an actor JWT directly in the actor filesystem
- (Potential) SystemInfoVolumes can provide an actor SPIFFE certificate (and private key) directly in the actor filesystem.
After working through dropping in GCP's agent gateway in place of the built-in Substrate egress gateway, it seems clear that it needs to be as simple as possible for any egress gateway to distinguish between an legitimate atunnel connection, and an actor spoofing an atunnel connection with its own certificate.
Right now, we distinguish between these cases with the "purpose" field in the Substrate X.509 extension. We should move this distinction into the SPIFFE URI, so that it is impossible to confuse "atunnel" versus "actor spoofing".
Right now and in the near future, we will have the following credential use cases:
After working through dropping in GCP's agent gateway in place of the built-in Substrate egress gateway, it seems clear that it needs to be as simple as possible for any egress gateway to distinguish between an legitimate atunnel connection, and an actor spoofing an atunnel connection with its own certificate.
Right now, we distinguish between these cases with the "purpose" field in the Substrate X.509 extension. We should move this distinction into the SPIFFE URI, so that it is impossible to confuse "atunnel" versus "actor spoofing".