tailscale / gitops-acl-action

GitOps for your Tailscale ACLs
85 stars 25 forks source link

Will Tailscale OAuth authentication be supported ? #19

Closed exo-cedric closed 9 months ago

exo-cedric commented 1 year ago

<-> (removed link)

(such as to work around the Max. 90 days API Key TTL)

DentonGentry commented 1 year ago

That doc isn't publicly searchable yet, the feature isn't in Alpha but is being prepared for it. It was made available to a very small number of sites, presumably including yours, as early access.

I've edited the issue to remove the link, we are not ready for a larger number of sites to start trying to use it.

I do expect to add support for OAuth API endpoints in this and other areas where we've produced something which needs a key. That work isn't done, and hasn't been started yet for some of them, because the OAuth feature isn't actually available yet for use.

korenyoni commented 1 year ago

(for context, OAuth Clients are now available in beta — https://tailscale.com/kb/1215/oauth-clients/)

See https://github.com/tailscale/gitops-acl-action/pull/20

name: Sync Tailscale ACLs

on:
  push:
    branches: ["main"]
  pull_request:
    branches: ["main"]

jobs:
  acls:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

      # https://tailscale.com/kb/1215/oauth-clients/#generating-long-lived-auth-keys
      # https://www.aaron-powell.com/posts/2022-07-14-working-with-add-mask-and-github-actions/
      - name: Generate API Token from OAuth App
        run: |
          TS_API_TOKEN=$(curl -d "client_id=${{ secrets.TS_OAUTH_CLIENT_ID }}" -d "client_secret=${{ secrets.TS_OAUTH_CLIENT_SECRET }}" \
            "https://api.tailscale.com/api/v2/oauth/token" | jq -r '.access_token')
          echo "::add-mask::$TS_API_TOKEN"
          echo TS_API_TOKEN=$TS_API_TOKEN >> $GITHUB_ENV

      - name: Deploy ACL
        if: github.event_name == 'push'
        id: deploy-acl
        uses: tailscale/gitops-acl-action@v1
        with:
          api-key: ${{ env.TS_API_TOKEN }}
          tailnet: ${{ secrets.TS_TAILNET }}
          action: apply
          policy-file: tailscale/policy.hujson

      - name: Test ACL
        if: github.event_name == 'pull_request'
        id: test-acl
        uses: tailscale/gitops-acl-action@v1
        with:
          api-key: ${{ env.TS_API_TOKEN}}
          tailnet: ${{ secrets.TS_TAILNET }}
          action: test
          policy-file: tailscale/policy.hujson

EDIT: apparently Tailscale wants to support this transparently in the GH action, but until that functionality is available, you can use the snippet above as a workaround.

bmillwood commented 1 year ago

It would be great if we could have this work in such a way that the test step can use an OAuth secret that only has read:acl scope, while the deploy step can use one with acl scope. That way, we can have anyone who opens a PR use credentials to check their change is good without letting them change the action in the workflow file to deploy from their PR before it is merged.

(We can do this by creating a GitHub environment, allowing that environment to only deploy from protected branches, and only giving the acl OAuth credentials to the environment, without having it available as a general actions secret.)

tobiasehlert commented 9 months ago

@exo-cedric; this issue should be fixed with the merge of #24.

@bmillwood; good point, you could create two oauth credentials and use them based on if it's a test or apply step maybe. probably some other things that can be done like approval of deploy into environment by codeowner or so as well.. the example workflow from the repo could be enhanced :)

ramblingenzyme commented 9 months ago

@tobiasehlert The v1 tag hasn't been updated / no new v1.x.x tag has been released, so consumers need to reference either main or the commit hash.

tobiasehlert commented 9 months ago

@tobiasehlert The v1 tag hasn't been updated / no new v1.x.x tag has been released, so consumers need to reference either main or the commit hash.

Yeah correct @ramblingenzyme. Using main is not that good, it's better to have commit hash to prevent weird things to happen to your workflows (which is what I use).

Based on the track record of release we'll see when there will be a new version, the last one was Sep 2022. Maybe @willnorris could look into a new release? :)

ramblingenzyme commented 9 months ago

@tobiasehlert A new release would be appreciated, it's very confusing when the GitHub Marketplace page shows the README.md from main and it still references using @v1. https://github.com/marketplace/actions/sync-tailscale-acls

willnorris commented 9 months ago

done. v1.1.0 tagged, and v1 updated. (Done manually for now... will need to switch to one of the various actions that are out there to automate this)