-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider an alternate certificate renewal flow that uses CSR #13
Comments
It may be worth reading and understanding https://spiffe.io/docs/latest/spire-about/spire-concepts/ to see if it is applicable. |
Resolves open-telemetry#13 Uses [Development] label as the indication of the least mature level proposed in this upcoming OTEP: open-telemetry/oteps#232
Resolves open-telemetry#13 Uses [Development] label as the indication of the least mature level proposed in this upcoming OTEP: open-telemetry/oteps#232
Resolves open-telemetry#13 Uses [Development] label as the indication of the least mature level proposed in this upcoming OTEP: open-telemetry/oteps#232
Resolves open-telemetry#13 Uses [Development] label as the indication of the least mature level proposed in this upcoming OTEP: open-telemetry/oteps#232
Resolves open-telemetry#13 Uses [Development] label as the indication of the least mature level proposed in this upcoming OTEP: open-telemetry/oteps#232
@tigrannajaryan this seems like it would be used in place of the |
I haven't looked in details of SPIFFE and don't know if/how we can use it. This requires someone to do some research and understand what SPIFFE does and how applicable it is to OpAMP. |
Resolves open-telemetry#13 Uses [Development] label as the indication of the least mature level proposed in this upcoming OTEP: open-telemetry/oteps#232
Resolves open-telemetry#13 Uses [Development] label as the indication of the least mature level proposed in this upcoming OTEP: open-telemetry/oteps#232
Resolves #13 Uses [Development] label as the indication of the least mature level proposed in this upcoming OTEP: open-telemetry/oteps#232
The client certificate creation is currently performed by the Server, with Server generating a private/public keypair and sending it to the Agent.
We could change the flow to use a CSR-like flow, where the Agent generates a keypair, a CSR and sends the CSR to the Server. I think this better mirrors the traditional certificate generation flow. The benefit will be that the private key does not leave the Agent.
This adds more complexity to the protocol (one extra roundtrip), but is worth exploring.
The text was updated successfully, but these errors were encountered: