Human identity for the control plane

[AlexSzlavik]

Problem statement

FTL's administrative tooling (via the FTL command line), does not authenticate requests. The current security model of the CLI tooling, which is the main / only way to affect control plane changes in a deployment, relies on a network perimeter to authenticate and authorize requests. This approach limits administrators from providing finer grained access to the control plane (say in a multi-tenant deployment), or segment responsibilities among different administrators (ie. SREs vs Infrastructure admins vs Module admins).

Solution sketch

An acceptable solution provides credentials, which a human operator may present to be authenticated and authorized to perform a non-strict subset of administrative actions. In the spirit of starting small, just requiring humans to be authenticated would be the initial goal, with authorization policy to follow later. I see roughly 2 approaches:

1. Adopt a kubernetes style authentication approach. Humans are issued client certificates, which are used for authentication. Credentials would be issued by the ftl-controller or the a new sub-component, responsible for managing access control at the control plane. Requests to the controller API would would be signed and the client certificate presented on every request. With this information, the controller would be able to authenticate every request and apply authorization logic.

2. Adopt OIDC based external authentication services. As FTL is targeting K8s + Istio, and managing istio authz polcies directly, FTL could also ship with something akin to OAuth2 proxy and a means to integrate with an upstream OIDC provider (such as GH, Okta, Google etc.). Authentication and authorization would be delegated to the traffic layer, with authorization headers also being propagated to the controller for fine grained, application level authorization control.

Additional considerations

Access to the control plane should be carefully gated but not lead to the potential for administrators to be completely locked out of their deployments. This is usually solved through root / system accounts, which can be used to recover other accounts. A pattern to consider here, is to mint a root client credential, which is further password protected, thus requiring both knowledge of the password and access to the encrypted credential.