Custom API Endpoint for Machine Account Key Creation

[JoseSzycho]

High-Level Summary

Develop a custom API endpoint in Milo for creating MachineAccountKey resources that supports automated key pair generation.

Motivation

Providing a way for users to create machine account keys without having to generate their own key pairs simplifies the onboarding process and ensures that keys are generated following security best practices. Returning the private key only once during creation prevents it from being stored in Milo, enhancing security.

Goals

• Implement a custom POST endpoint for MachineAccountKey at /v1alpha1/namespaces/{namespace}/machineaccountkeys.
• Accept an optional publicKey field in the request body.
• If the publicKey is null or omitted:
  • Automatically generate a secure RSA (2048-bit) key pair.
  • Populate the publicKey field in the MachineAccountKey resource spec.
  • Return the generated private key in the response status body.
• If the publicKey is provided:
  • Use the provided public key in the MachineAccountKey resource.
  • Do not return a private key in the response.
• Return the created MachineAccountKey resource in the response body in all scenarios.
• Ensure the endpoint properly integrates with the Kubernetes API to create the resource.

Non-Goals

• Storing the private key anywhere in Milo's backend or status.
• Providing a mechanism to retrieve the private key after the initial creation response.
• High-level key rotation logic (handled by the controller).
• Implementation of the auth-provider-zitadel controller (this is tracked in another ticket).

[JoseSzycho]

@scotwells I had some issues when implementing a RESTStorageProvider for the machineAccountKeys, as that RESTStorageProvider takes over the entire group's discovery endpoint, causing all IAM CRDs resource to vanish.

I'm now thinking into implementing a HTTP middleware that intercepts the POSTS, and wraps the response writer to inject status.privateKey when a user does not provide a public key (scenario when user does not provide a public key).

Any thoughts on that approach?

[scotwells]

@JoseSzycho did you try using the identity API group since we're already using a custom storage layer there?

[JoseSzycho]

@scotwells No, I didn't. For doing this we should migrate the MachineAccountKey from the IAM api group to the identity group, right?