action.yml,src: add support for workload identity federation #221

mpminardi · 2025-10-27T15:10:40Z

Add support for workload identity federation based authentication.

Updates https://github.com/tailscale/corp/issues/31264

mpminardi · 2025-10-27T15:11:22Z

TODO: setup tests using workload identity

src/main.ts

oxtoacart

Generally LGTM, just one question.

mcoulombe · 2025-10-27T18:03:18Z

src/main.ts

+      authArgs.push(`--client-id=${config.oauthClientId}`);
+      authArgs.push(`--id-token=${token}`);
+    }
+  }


What's the behaviour if a user provides an audience + clientID but their Tailscale version is <1.90.x? Do we fail gracefully or they get a generic "arguments do not exist" message?

Is it worth being more defensive and checking the CLI version to surface a more obvious error message?

Have added a check here

mcoulombe · 2025-10-27T18:08:23Z

action.yml

    deprecationMessage: 'An OAuth API client https://tailscale.com/s/oauth-clients is recommended instead of an authkey'
  oauth-client-id:
-    description: 'Your Tailscale OAuth Client ID.'
+    description: 'Your Tailscale OAuth or Workload Identity Federation Client ID.'


I think I heard the new "type" of client referred to as Federated client instead of Workload Identity Federation client. i'm not sure if we have an official term yet but I have a slight preference for the shorter variation.

I see the UI now refers to this concept as Trusted Credentials, so should that be Your OIDC trusted Credentials Client ID? Are we switching "client" to "trusted credentials" everywhere so people do not confuse them for separate concepts and resources?

We're generally swapping "client" for "credentials" except for the ClientID itself given that this client_id in the API / for the spec, so potentially something like ...Federated Identity clientID or `...OIDC Federated Identity clientID would work here.

mcoulombe · 2025-10-27T18:21:47Z

README.md

+  id-token: write # This is required for the tailscale action to request a JWT from GitHub
+```
+
+Federated identity credentials used for this purpose must have the [`auth_keys` scope.][kb-trust-credentials-scopes]


I know this is implied because our scopes do not have :write variants, but we should find a way to be more explicit this is a write scope. There is an issue already that indicates not calling out this is a write scope is confusing.

Maybe something like this?

Suggested change

Federated identity credentials used for this purpose must have the [`auth_keys` scope.][kb-trust-credentials-scopes]

Federated identity credentials used for this purpose must have the writable [`auth_keys` scope.][kb-trust-credentials-scopes]

mcoulombe · 2025-10-27T18:26:28Z

README.md

 ### requested tags [tag:mytag] are invalid or not permitted

-You may encounter this error when using an OAuth client. OAuth clients must have the [`auth_keys` scope](https://tailscale.com/kb/1215/oauth-clients#scopes) with one or more [tags](https://tailscale.com/kb/1068/acl-tags/), and the tags specified with `tags` must match all tags on the OAuth client.
+You may encounter this error when using an OAuth client. OAuth clients must have the [`auth_keys` scope][kb-trust-credentials-scopes] with one or more [tags][kb-tags], and the tags specified with `tags` must match all tags on the OAuth client.


General thought unrelated to the PR:

If the tags passed on the Tailscale CLI command MUST match all tags configured on the client, why is it a configurable input? Is there a reason we cannot take care of this server-side and make the --tags argument optional?

Ah didn't catch this when adjusting / when the PR for the original change flew by. This can also be tags owned by the tags associated with the client.

E.g., assuming a policy file with:

"tagOwners": { "tag:main": ["autogroup:admin", "autogroup:owner"], "tag:test-tag": ["autogroup:admin", "autogroup:owner", "tag:main"], "tag:test-tag-2": ["autogroup:admin", "autogroup:owner", "tag:main"], }

and a trust credential that has tag:main applied, then --tags could be any of tag:main, tag:test-tag, or tag:test-tag-2.

TIL tags can own tags

mcoulombe · 2025-10-27T18:28:35Z

README.md

+on tailnets which use [Device Approval][kb-device-approval]
+
+
+### Workload identity federation


Should we mark this as the preferred method? Potentially even use it for the default example starting on l.6?

Good call! Had been thinking that we might want to leave this as-is for beta, but I feel like there's no harm in swapping this now given the improved UX / security posture.

I'm fine either way, I see your point that for the Beta phase there could be bugs or rough edges that make authkeys the preferable default for a little longer.

Will leave it as-is for now, can adjust later

mcoulombe · 2025-10-27T18:31:21Z

README.md

-1. At least one configured [tag][kb-tags].
-1. An [OAuth client][kb-oauth-clients] ID and secret OR an [auth key][kb-auth-keys].
+1. At least one configured [tag][kb-tags] if using OAuth or workload identity federation.
+1. An [OAuth client][kb-oauth-clients] ID and secret, [federated identity][kb-workload-identity-federation] client ID and audience, OR an [auth key][kb-auth-keys].


Will the KB have a section tailored to setup a federated client compatible with GitHub? If not how will people know what issuer URL, subject and audience they should use?

mcoulombe · 2025-10-27T19:12:16Z

src/main.ts


  // Prepare auth and tags
-  let finalAuthKey = config.authKey;
+  const authArgs: string[] = [];


We should have a test that verifies the priority order when arguments for multiple auth methods are provided.

Even better might be to check that you only specify one, and if it's ambiguous, bail.

Careful though because at the moment if someone passes both a client secret and an authkey the authkey has precedence, we bailing if both are provided is breaking.

Yeah I think we're at the point where we should look at adding proper unit testing of some of these functions / flows. Going to punt on that for now but have filed https://github.com/tailscale/corp/issues/33870 to track

mcoulombe

Read through the PR again and that looks good to me. I trust you for any doc adjustments we may want to do based on the comments, and we can always adjust defensive checks and READMEs later.

mpminardi · 2025-10-28T21:27:36Z

package.json

    "@actions/github": "^6.0.1",
-    "@actions/tool-cache": "^2.0.1"
+    "@actions/tool-cache": "^2.0.1",
+    "semver": "^6.3.1"


We were already transitively depending on this, explicitly added here to surface the dependency better

oxtoacart

LGTM, I have just one comment about the priority order of authentication arguments that probably worth resolving.

oxtoacart · 2025-10-29T11:27:41Z

src/main.ts


-  if (config.oauthSecret) {
-    finalAuthKey = `${config.oauthSecret}?preauthorized=true&ephemeral=true`;
+  if (config.authKey) {


This changes the priority order relative to the current v4, in which config.oauthSecret took priority over config.authKey. If we're going to do that, we might as well just add validation that ensures you've only specified one or the other, not both.

Whoops! Will flip back to oauthSecret having priority over the authKey for now.

Add support for workload identity federation based authentication. Updates tailscale/corp#31264 Signed-off-by: Mario Minardi <[email protected]>

mpminardi requested review from jaxxstorm, mcoulombe and oxtoacart October 27, 2025 15:10

mpminardi self-assigned this Oct 27, 2025

mpminardi force-pushed the mpminardi/workload-identity branch 2 times, most recently from c64c251 to c75f428 Compare October 27, 2025 15:15

oxtoacart reviewed Oct 27, 2025

View reviewed changes

src/main.ts Show resolved Hide resolved

oxtoacart reviewed Oct 27, 2025

View reviewed changes

mcoulombe reviewed Oct 27, 2025

View reviewed changes

mpminardi force-pushed the mpminardi/workload-identity branch from c75f428 to e129d0b Compare October 27, 2025 19:04

mcoulombe reviewed Oct 27, 2025

View reviewed changes

mpminardi force-pushed the mpminardi/workload-identity branch 5 times, most recently from 962d174 to 45d945b Compare October 28, 2025 03:36

mcoulombe approved these changes Oct 28, 2025

View reviewed changes

mpminardi force-pushed the mpminardi/workload-identity branch from 45d945b to 653d5ed Compare October 28, 2025 21:19

mpminardi commented Oct 28, 2025

View reviewed changes

oxtoacart approved these changes Oct 29, 2025

View reviewed changes

action.yml,src: add support for workload identity federation

ef403f0

Add support for workload identity federation based authentication. Updates tailscale/corp#31264 Signed-off-by: Mario Minardi <[email protected]>

mpminardi force-pushed the mpminardi/workload-identity branch from 653d5ed to ef403f0 Compare October 29, 2025 13:52

mpminardi merged commit a392da0 into main Oct 30, 2025
28 checks passed

mpminardi deleted the mpminardi/workload-identity branch October 30, 2025 14:07

mcoulombe mentioned this pull request Nov 10, 2025

README: clarify auth_key scope must be writable #228

Merged

	Federated identity credentials used for this purpose must have the [`auth_keys` scope.][kb-trust-credentials-scopes]
	Federated identity credentials used for this purpose must have the writable [`auth_keys` scope.][kb-trust-credentials-scopes]

		on tailnets which use [Device Approval][kb-device-approval]


		### Workload identity federation

action.yml,src: add support for workload identity federation #221

action.yml,src: add support for workload identity federation #221

Uh oh!

Conversation

mpminardi commented Oct 27, 2025

Uh oh!

mpminardi commented Oct 27, 2025

Uh oh!

Uh oh!

oxtoacart left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

oxtoacart Oct 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mcoulombe Oct 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mcoulombe left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

oxtoacart left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

oxtoacart Oct 27, 2025 •

edited

Loading

mcoulombe Oct 27, 2025 •

edited

Loading

mcoulombe left a comment •

edited

Loading