FR: Allow creating new OAuth clients using the API

[grelland]

What are you trying to do?

We're automating provisioning of various infrastructure which needs to connect to Tailnet. In order to make (tag scoped) auth keys available to services we've had to build custom, centralized automation to manage provisioning and rotation of auth keys (using OAuth client credentials), which in turn are made available to services.

If we instead could automate provisioning of OAuth client credentials that are handed directly to these services, we would do away with a lot of complexity.

One example of a use case is the first party GitHub Action, which recommends using OAuth credentials rather than auth keys. You'd then need to manually create OAuth client credentials and provide them to the action. This is fine, but doesn't scale for our use case where multiple teams are running CI jobs which require access to entirely different tags on our Tailnet - this is of course very tedious to manually dish out credentials for, but a complete breeze using something like Terraform.

How should we solve this?

1. Add an OAuth scope for creating new OAuth clients, or make it part of all
2. Expose the API to create and revoke OAuth clients
3. Bonus: Implement support in tailscale-client-go + terraform-provider-tailscale

What is the impact of not solving this?

In our case: We could shut down a complicated bespoke service to handle auth key provisioning and rotation across services. Generally: This is IMO the missing piece to complete the automation user story for Tailscale.

Anything else?

No response

[DentonGentry]

One example of a use case is the first party GitHub Action

Do all of the benefits in your bespoke auth system derive from having a mechanism which never expires to create Tagged nodes? If a single OAuth client could allocate authkeys which carry a specific set of tags and never expire, would that meet the need?

[grelland]

Do all of the benefits in your bespoke auth system derive from having a mechanism which never expires to create Tagged nodes?

Kind of. For context, I'll elaborate:

In the case of GitHub Actions we combine said system with provisioning OIDC trust to Google Cloud. The Actions runner can then fetch the (tagged, reusable, ephemeral) auth key from a Google Secret, connect to Tailnet, and go about it's business. Infrastructure on both sides is set up in a centralized Terraform configuration, so the end user will just add a small bit of config to get going for their repo/environment. There is a service that handles creation and rotation auth keys, and updating the Google Secret.

The benefit is really in full automation, and due to auth key expiry we also need key rotation, currently.

The relation to this FR is that we could simplify this flow a lot if we could instead provision OAuth client credentials for the GitHub repo directly (and stash it there as Actions secrets), and use those instead.

If a single OAuth client could allocate authkeys which carry a specific set of tags and never expire, would that meet the need?

Not quite. We would still need to run a centralized thing to dish out authkeys in that case, as we need to separate privileges to use tags based on environment, GitHub repo etc. What we do today is use an OAuth client with the all scope for the centralized authkey service.

We also employ the exact same service and mechanism to provision auth keys for subnet routers across all our VPCs. In the same manner, access to a tagged and non-expired auth key needs to be fully automated as part of provisioning the VPC + router VM - and privileges have to be scoped to specific tags for specific environments.

Given that this feature is implemented we could instead use Terraform to create OAuth client credentials, put those in some secret storage in the environment and let the subnet router create auth keys as needed.

The same would be achievable if auth keys could have infinite expiry, but I'm sure that's out of the question. :)

[grelland]

Any chance this will get traction?

[mattmoyer]

My org would also use an API like this to implement automatic scheduled rotation of client credentials. For example, we use an OAuth client in our Terraform automation. We would like to be able to write an AWS Secrets Manager rotation Lambda for this credential, but we currently cannot since there's no public API available.

[heretic098]

Another use case, per https://github.com/tailscale/terraform-provider-tailscale/issues/283 is to be able to fully automate the installation of the k8s operator. Currently I have to create the oauth client by hand and then feed the credentials in making it a pain to provision the tailscale operator across all my k8s clusters.

Just to expand a little, I want one oauth client per k8s cluster so that I can control the ACL to allow only traffic to/from certain cluster resources. I don't want all my clusters to be allowed to create devices with the same ACL tag so that I can separate the traffic.

[la3mmchen]

Any news on this? We have a myriad of hand-managed OAuth clients in Tailscale and would love to manage them somehow - preferably with Terraform.