The revoke-keys command allows nodes with tailnet lock keys
to collaborate to erase the use of a compromised key, and remove trust
in it.
Signed-off-by: Tom DNetto <tom@tailscale.com>
Updates ENG-1848
* tka: provide verify-deeplink local API endpoint
Fixes https://github.com/tailscale/tailscale/issues/8302
Signed-off-by: Andrea Gottardo <andrea@tailscale.com>
Address code review comments
Signed-off-by: Andrea Gottardo <andrea@tailscale.com>
Address code review comments by Ross
Signed-off-by: Andrea Gottardo <andrea@tailscale.com>
* Improve error encoding, fix logic error
Signed-off-by: Andrea Gottardo <andrea@tailscale.com>
---------
Signed-off-by: Andrea Gottardo <andrea@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>
* Do not print the status at the end of a successful operation
* Ensure the key of the current node is actually trusted to make these changes
Signed-off-by: Tom DNetto <tom@tailscale.com>
Previously, `TAILSCALE_USE_WIP_CODE` was needed to hit a bunch of the TKA paths. With
this change:
- Enablement codepaths (NetworkLockInit) and initialization codepaths (tkaBootstrapFromGenesisLocked via tkaSyncIfNeeded)
require either the WIP envknob or CapabilityTailnetLockAlpha.
- Normal operation codepaths (tkaSyncIfNeeded, tkaFilterNetmapLocked) require TKA to be initialized, or either-or the
envknob / capability.
- Auxillary commands (ie: changing tka keys) require TKA to be initialized.
The end result is that it shouldn't be possible to initialize TKA (or subsequently use any of its features) without being
sent the capability or setting the envknob on tailscaled yourself.
I've also pulled out a bunch of unnecessary checks for CanSupportNetworkLock().
Signed-off-by: Tom DNetto <tom@tailscale.com>
This reverts commit f1130421f0.
It was submitted with failing tests (go generate checks)
Requires a lot of API changes to fix so rolling back instead of
forward.
Change-Id: I024e8885c0ed44675d3028a662f386dda811f2ad
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
This commit implements `tailscale lock log [--limit N]`, which displays an ordered list
of changes to network-lock state in a manner familiar to `git log`.
Signed-off-by: Tom DNetto <tom@tailscale.com>
By always firing off a sync after enablement, the control plane should know the node's TKA head
at all times.
Signed-off-by: Tom DNetto <tom@tailscale.com>
This moves the NetworkLock key from a dedicated StateKey to be part of the persist.Persist struct.
This struct is stored as part for ipn.Prefs and is also the place where we store the NodeKey.
It also moves the ChonkDir from "/tka" to "/tka-profile/<profile-id>". The rename was intentional
to be able to delete the "/tka" dir if it exists.
This means that we will have a unique key per profile, and a unique directory per profile.
Note: `tailscale logout` will delete the entire profile, including any keys. It currently does not
delete the ChonkDir.
Signed-off-by: Maisem Ali <maisem@tailscale.com>
Found by tests in another repo. TKA code wasn't always checking enough to be sure a node-key was set for the current state.
Signed-off-by: Tom DNetto <tom@tailscale.com>
* Plumb disablement values through some of the internals of TKA enablement.
* Transmit the node's TKA hash at the end of sync so the control plane understands each node's head.
* Implement /machine/tka/disable RPC to actuate disablement on the control plane.
There is a partner PR for the control server I'll send shortly.
Signed-off-by: Tom DNetto <tom@tailscale.com>
Running corp/ipn#TestNetworkLockE2E has a 1/300 chance of failing, and
deskchecking suggests thats whats happening are two netmaps are racing each
other to be processed through tkaSyncIfNeededLocked. This happens in the
first place because we release b.mu during network RPCs.
To fix this, we make the tka sync logic an exclusive section, so two
netmaps will need to wait for tka sync to complete serially (which is what
we would want anyway, as the second run through probably wont need to
sync).
Signed-off-by: Tom DNetto <tom@tailscale.com>
* tka.State.staticValidateCheckpoint could call methods on a contained key prior to calling StaticValidate on that key
* Remove broken backoff / RPC retry logic from tka methods in ipn/ipnlocal, to be fixed at a later time
* Fix NetworkLockModify() which would attempt to take b.mu twice and deadlock, remove now-unused dependence on netmap
* Add methods on ipnlocal.LocalBackend to be used in integration tests
* Use TAILSCALE_USE_WIP_CODE as the feature flag so it can be manipulated in tests
Signed-off-by: Tom DNetto <tom@tailscale.com>
This will be needed to support preauth-keys with network lock in the future,
so getting the core mechanics out of the way now.
Signed-off-by: Tom DNetto <tom@tailscale.com>
Updates #5435
Based on the discussion in #5435, we can better support transactional data models
by making the underlying storage layer a parameter (which can be specialized for
the request) rather than a long-lived member of Authority.
Now that Authority is just an instantaneous snapshot of state, we can do things
like provide idempotent methods and make it cloneable, too.
Signed-off-by: Tom DNetto <tom@tailscale.com>
