Currently this would validate that a KeyId was in the returned wrapper
but then return the base wrapper; and if it required a database lookup
it wouldn't validate it anyways.
All uses of this were for decryption so it didn't actually affect
anything to this point (you'd error later instead of sooner) but for any
case where we need to encrypt against a specific version or derive a key
against a specific version this would be broken, in a way that could
lead you to use the wrong key version.
This also properly sends the Key ID around sessions. This worked
currently for the same reason as above but would have broken for any
session in flight once a key was rotated.
* Sessions support for read:self and cancel:self permissions. This is automatic with fallback; no API change is needed.
* Strips out values from listing if only self actions are allowed on the resource and the user ID is different. This prevents a default ACL of id=*;type=session;actions=read:self,cancel:self from causing all values to be visible when listing.
* Adds an unprivileged user to development/testing instances. This user has only default permissions plus the ability to authorize sessions in the default target.
* Remove list:self from main
As per futher discussions, we won't be supporting this, in favor of
simply read:self and cancel:self (since listing now already filters out
items on which you have no permissions).
This doesn't remove list:self entirely from the code base as much of
that will simply be converted to read:self and cancel:self -- that will
be in a later PR. However, with this removed if we want to release we
won't expose an API publicly that isn't going to stick around.
Create Schema Manager and propagate contexts into the DB calls downstream.
Add checks at controller startup and database init for correct schema version and schema migration dirty bit being set.
This returns authorized actions on targets to users when they perform an operation on a target, including listing. It also prevents users from seeing values in listing targets on which they have no permissions.
* Attempt canceling sessions by the client
In some circumstances (like a Ctrl-C), the client knows it's shutting
down and the TOFU token will be lost. In this case it makes sense to
cancel the session rather than have it time out. This introduces a
command enum to the handshake message which can be used for the client
to send commands to the worker -- in this case the only specified
command is to cancel the session. It doesn't occur if the session is
already timed out or if we can't authorize connections as this generally
means the session is already invalid.
This is a wire breaking change for json errors since we have removed and renamed a few fields, and changed part of the structure of the returned json error.
* Remove redundant fields in Status, details.error_id, details.TraceId and details.request_id from API errors.
* Added wrapped errors and "ops" field to indicate the internal operation of the errors returned by the API.
* Added error cli error reporting of Op and wrapped errors.
* feat: make auth token time to live and staleness configurable
* docs: add configuration docs for auth token TTL and staleness
Co-authored-by: Jeff Mitchell <jeffrey.mitchell@gmail.com>
* Update deps
This also updates for the new (and required) paradigm for registering
service implementations as spelled out in
https://github.com/grpc/grpc-go/issues/3385
* Roll back dockertest
This was always an RPC-only distinction and from that perspective it
makes sense; however it causes the generated docs to treat it as an
entirely separate service even though it's under the same collection
path as auth methods and this is confusing.
Go's TLS stack doesn't need a separate CA cert and in fact for sessions
we don't use this. So simplify the worker connection to remove an
unnecessary extra key generation.
Louis Ruch
Jeff Mitchell
Todd Knight
Michael GaffneyandJeff Mitchell
Jeff MalnickandJeff Mitchell
Jim
Lars Lehtonen