Datum Tunnels - Discussion on Authorization

[mksinghtx]

Capturing the the discussion on the following 2 items from a Feature alignment document prepared by @zsmithnyc
Datum Tunnels - Feature alignment doc

• OAuth 2.0 / OIDC integration with Datum identity platform for GUI clients, Machine Accounts for headless
• Support for Machine Account (?)

[@mksinghtx ]The top question on my mind are How does the agent enroll in the Datum tunnel service? and how does it renew(automate via agent) and how often? What is the Identity and how is it allocated or retrieved. One example it is retrieved from an IDP using a MachineIdentity and mapped to a group, role. Or it could very well be that it is a service account impersonating a user(Cloud case- AWS, GCP). Another ID allocation is when an agent is downloaded or built - a unique ID is generated(using time+OS+device ID+entropy), if a container is running the agent a container-ID is used. In this case Agent uses the ID in enrollment API to Datum, get a group- (machine group ) from the Datum auth token and map it to a role via IAM, if no group can be deduced then ID is mapped to lowest privileged role - (have low quota- to be safe). Generate CSR on agent and send it over to Datum to get signed cert or the agents can get certs that can be trusted from LE/Digicert etc, that would secure the channel and serve to bring up tunnels to Datum.

[@joshlreese ]Initially, authentication tokens would be obtained via datumctl, which could be configured with either the OIDC flow as it is today (user auth) or a machine account credential (a public / private key pair). The identities associated with the user or machine accounts are bound to roles in IAM policies which control what they're able to do. In the future, network policies within a VPC could leverage identity attributes to apply policy.

Future authentication approaches could include capabilities similar to what GCP's Workload Identity Federation0 provides, where a user would configure their Datum identity pool to trust tokens issued by third parties. When combined with a feature like Kubernetes' ServiceAccount token volume projection1, the application can simply expect to read a token from a well known location on the filesystem, and expect that the orchestration system is responsible for refreshing and rotating the token.

Additionally, I believe SPIFFE2 is now the de facto standard for workload identity, and should be evaluated further to see how Datum can work with it.

@joshlreese • 9:33 AM, Oct 21 (PDT)
@mksinghtx - I think that needs to be scoped out for a future phase. I think it's best to start with the agent having a single identity - I believe SPIFFE has mechanisms for scoping tokens based on that identity, which may be possible to use for per-tunnel / per connection auth.

@mksinghtx • 11:25 AM, Oct 21 (PDT)
Sounds good, I wanted to understand the certificates though for mTLS and tunnels - if raw keys will be used then how are we distributing those - @[email protected] for context https://datatracker.ietf.org/doc/html/rfc7250#section-3

@joshlreese • 11:30 AM, Oct 21 (PDT)
@mksinghtx - The API for machine account keys supports either providing a public key for a pre-generated key pair, or to have Datum generate both public and private keys, where the client will be responsible for management of the private key once returned. Datum does not store private key material.
These keys would need to be configured ahead of time, and provided to the agent.

@scotwells • 11:36 AM, Oct 21 (PDT)
More information available on the enhancement for machine-to-machine authentication: https://github.com/datum-cloud/enhancements/tree/main/enhancements/platform/identity-and-access-management/authentication#machine-account-and-machine-account-key-management

@mksinghtx 6:47 PM, Oct 21 (PDT)New
will ask the rest of my questions in enhancement - just one clarification - Enrollment to my mind means getting keys through that process and should not need to be apriori - takes away from the User experience.