feat: use Workload Identity Federation for authentication#63
Open
kobim wants to merge 1 commit intotailscale:mainfrom
Open
feat: use Workload Identity Federation for authentication#63kobim wants to merge 1 commit intotailscale:mainfrom
kobim wants to merge 1 commit intotailscale:mainfrom
Conversation
bouk
reviewed
Jan 21, 2026
action.yml
Outdated
| TS_API_KEY: "${{ inputs.api-key }}" | ||
| TS_API_KEY: "${{ steps.tailscale_api_key.outputs.access_token }}" | ||
| TS_TAILNET: "${{ inputs.tailnet }}" | ||
| run: go run tailscale.com/cmd/gitops-pusher@66aa77416744037baec93206ae212012a2314f83 "--policy-file=${{ inputs.policy-file }}" "${{ inputs.action }}" |
There was a problem hiding this comment.
You can pass TS_ID_TOKEN to gitops-pusher https://github.com/tailscale/tailscale/blob/2cb86cf65eb8908d34f93a7587807cde6ecf979c/cmd/gitops-pusher/gitops-pusher.go#L238
Author
There was a problem hiding this comment.
that's pretty new and would also save a few lines from this PR. I updated the branch with your suggestion, thank you!
With the latest introduction of [Workload Identity Federation](https://tailscale.com/kb/1581/workload-identity-federation), there's an idiomatic mechanism for authenticating to Tailscale from Github Actions jobs without having to store any credentials (API Key / OAuth client secret) in Github Actions. The latest version of the action contained two different authentication options - API Key and OAuth Client. API Keys have time limit (maximum 90 days) and require rotation. With the introduction of OAuth clients and now Workload Identity Federation, we should discourage the usage of an expiring secret that can be used outside of Github Actions. OAuth clients introduced the need to store an additional credentials (OAuth Client ID & Secret) in Github Actions. As these credentials can be used everywhere, there's no guarentee they will only be used in the context of a Github Actions job. OpenID Connect and the implementation of Workload Identity Federation allows to **encourage** best practices by *forcing* the user to use these instead of any of the above. Leaving a single authentication method would also simplify the implementation of this Action - there's no need to validate which set of `inputs` was set, and later on we could also remove the [OAuth-related functionality from `gitops-pusher` itself](https://github.com/tailscale/tailscale/blob/2cb86cf65eb8908d34f93a7587807cde6ecf979c/cmd/gitops-pusher/gitops-pusher.go#L246-L254).
kobim
force-pushed
the
feat/replace-auth-with-workload-identity
branch
from
046dc72 to
e99a2e7
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
With the latest introduction of Workload Identity Federation, there's an idiomatic mechanism for authenticating to Tailscale from Github Actions jobs without having to store any credentials (API Key / OAuth client secret) in Github Actions.
Resolves #62
Open Discussion: removing the other authentication options
The latest version of the action contained two different authentication options - API Key and OAuth Client.
API Keys have time limit (maximum 90 days) and require rotation. With the introduction of OAuth clients and now Workload Identity Federation, we should discourage the usage of an expiring secret that can be used outside of Github Actions.
OAuth clients introduced the need to store an additional credentials (OAuth Client ID & Secret) in Github Actions. As these credentials can be used everywhere, there's no guarentee they will only be used in the context of a Github Actions job.
OpenID Connect and the implementation of Workload Identity Federation allows to encourage best practices by forcing the user to use these instead of any of the above.
Leaving a single authentication method would also simplify the implementation of this Action - there's no need to validate which set of
inputswas set, and later on we could also remove the OAuth-related functionality fromgitops-pusheritself.