Smoosh CredentialBroker and WorkerCapacity into AteomSupport - #1501
Conversation
Benjamin Elder (BenTheElder)
left a comment
Benjamin Elder (BenTheElder)
left a comment
There was a problem hiding this comment.
second commit LGTM
ee33926 to
f7ca38b
Compare
| // Create a Substrate-issued JWT asserting the actor identity. | ||
| // | ||
| // * Called by the egress gateway when actor JWT injection is configured for outbound requests. | ||
| rpc MintActorJWT(MintActorJWTRequest) returns (MintActorJWTResponse) {} | ||
|
|
||
| // Create a Substrate-issued SPIFFE certificate asserting the actor identity. | ||
| // | ||
| // * Called by atelet to provision an atunnel with a certificate for | ||
| // communication with the egress gateway. TODO(ahmedtd): Migrate this use | ||
| // case to a distinct certificate to prevent actor/atunnel confusion. | ||
| // * Called by the egress gateway when actor client certificate injection is | ||
| // configured for outbound requests. | ||
| rpc MintActorCertificate(MintActorCertificateRequest) returns (MintActorCertificateResponse) {} |
There was a problem hiding this comment.
I'm not so sure I agree with this change. From a logical/security perspective these seem fairly different than the rest of these services. I understand that from an RBAC perspective we can treat them differently, but it can help to logically separate things which have different responsibilities.
There was a problem hiding this comment.
I think the likely end state here is:
-
MintActorJWT/Certificate in Control API. These are called by the egress gateway, as well as customer harnesses in front of substrate, to get credentials for actions that should be undertaken as "the actor".
-
MintAteomActorCertificate in a new, atelet/ateom-focused API also served by ateapi. This would vend certs for atunnel to connect to the egress gateway. There's still some active debate on whether or not the API actually needs to be split in this way.
There was a problem hiding this comment.
I think the specifics of what the support API look like also depend on whether atelet will still be around at GA, or if multi-actor ateoms will be connected directly to ateapi.
There was a problem hiding this comment.
Strictly based on the comments above it sounds like there are open questions here which should be resolved before this PR?
There was a problem hiding this comment.
No, I think the only question is which gRPC "service" the RPCs will be in on ateapi. The actual form and purpose of the RPCs is pretty clear.
f7ca38b to
86870d3
Compare
|
This is now unstacked. |
3 participants
We shouldn't have a bunch of different gRPC services for atelet to provide services to ateoms. Combine the two that currently exist into one (AteomSupport).