gitops-pusher supports authenticating with an API key or OAuth
credentials (added in #7393). You shouldn't ever use both of those
together, so we error if both are set.
In tailscale/gitops-acl-action#24, OAuth support is being added to the
GitHub action. In that environment, both the TS_API_KEY and OAuth
variables will be set, even if they are empty values. This causes an
error in gitops-pusher which expects only one to be set.
Update gitops-pusher to check that only one set of environment variables
are non-empty, rather than just checking if they are set.
Updates #7393
Signed-off-by: Will Norris <will@tailscale.com>
This changes the ACLTestError type to reuse the existing/identical
types from the ACL implementation, to avoid issues in the future if
the two types fall out of sync.
Updates #8645
Signed-off-by: Jenny Zhang <jz@tailscale.com>
This updates all source files to use a new standard header for copyright
and license declaration. Notably, copyright no longer includes a date,
and we now use the standard SPDX-License-Identifier header.
This commit was done almost entirely mechanically with perl, and then
some minimal manual fixes.
Updates #6865
Signed-off-by: Will Norris <will@tailscale.com>
Apparently the validate route doesn't check content-types or handle
hujson with comments correctly. This patch makes gitops-pusher convert
the hujson to normal json.
Signed-off-by: Xe <xe@tailscale.com>
Signed-off-by: Xe <xe@tailscale.com>
This makes a "modified externally" error turn into a "modified externally" warning. It means CI won't fail if someone does something manually in the admin console.
Signed-off-by: Xe <xe@tailscale.com>
This allows gitops-pusher to detect external ACL changes. I'm not
sure what to call this problem, so I've been calling it the "three
version problem" in my notes. The basic problem is that at any given
time we only have two versions of the ACL file at any given point:
the version in CONTROL and the one in the git repo. In order to
check if there has been tampering of the ACL files in the admin
panel, we need to have a _third_ version to compare against.
In this case I am not storing the old ACL entirely (though that could
be a reasonable thing to add in the future), but only its sha256sum.
This allows us to detect if the shasum in control matches the shasum
we expect, and if that expectation fails, then we can react
accordingly.
This will require additional configuration in CI, but I'm sure that
can be done.
Signed-off-by: Xe <xe@tailscale.com>
Apparently the API for running ACL tests returns a 200 if the ACL tests
fail. This is weird, but we can handle it.
Signed-off-by: Xe <xe@tailscale.com>
This is for an upcoming blogpost on how to manage Tailscale ACLs using a
GitOps flow. This tool is intended to be used in CI and will allow users
to have a git repository be the ultimate source of truth for their ACL
file. This enables ACL changes to be proposed, approved and discussed
before they are applied.
Signed-off-by: Xe <xe@tailscale.com>
