This adds a new requirement onto subtypes to register a NewFunc.
Previously the subtypes where implementing this function anyway, but the
target package was not including them in the registry. This resulted in
packages that use the target package needing to import the subtypes
directly, which we want to avoid.
This refactor will require the subtypes to register their NewFunc which
can then be used by `target.New` so packages that need to create targets
can do so by only using the target package.
This also updates the tcp subpackage to register a NewFunc.
* refactor (controller): Use a grpc server for the grpc-gateway
This starts a grpc server for the grpc-gateway. The new gateway
server uses an in-memory listener which also supports "dialing", so
the http proxy can connect to the in-memory listener.
This change allows us to use all grpc server features and was in part
motivated by a need for an interceptor of inbound requests. With that
said, having a "proper" grpc server for the gateway will provide a lot
more flexibility and capabilities moving forward.
The request context will still be verified via middleware in the
http proxy (see wrapHandlerWithCommonFuncs). This verified context
will be serialized into a protobuf and sent along to the grpc-gateway
via metadata where an interceptor will add the verified request
info to the request's context (see requestCtxInterceptor). The
interceptor will verify the serialized request info via a shared ticket
with it's companion in-memory http proxy. FYI: the ticket is simply
random base62 string (see db.NewPrivateId).
This change also necessitated a minor change to services. We need to
return an empty response instead of nil, nil when there are no errors
and the response is empty.
* refactor (handlers): Rename gRPC Gateway filter
Originally, this was called an OutgoingInterceptor, which is an
unfortunate name since it's not an interceptor. Now that we're
refactoring the gateway stuff and have proper interceptors, renaming
this should remove ambiguity
* refactor: Rework how 204 with empty msg is handled
Recent changes to grpc gateway has necessitated a change to how
204s are handled by the gateway
* tests (bats): Check status codes for delete operations
This moves all of the tcp target functionality into a tcp package. It
also establishes a Register function in the target package to allow
specific target types to be registered at initilazation time. When
registering, a target type needs to provide its Subtype, as well as some
RepositoryHooks that are used by the target Repository.
The existing logic was to ignore Forbidden errors when recursively
listing in favor of looking for downstream scopes with appropriate
permissions. The problem is that when there is actually no
authentication token at all, what comes back is an Unauthenticated
error. Therefore if you didn't have permissions on the ingress scope
(e.g. the default of `global`) but did downstream for the anonymous
user, you'd get back an error.
I don't think there's any security issue with doing this; the user could
always have simply started the search at a downstream scope to begin
with so nothing more is being revealed, this just fixes behavior to
match expectations in this case.
A test was added for one of the services; the code is exactly the same
across them. The reason that the existing tests that were added with the
output fields testing didn't catch this is that even though they were
specifying `u_anon` as the user, the disabled test context skipped the
logic that would return a 401 in this case. It turns out that fixing
this is very complicated because we don't have a great way in most tests
of defining grants to put onto the generated scopes, so even if a true
anonymous context was added each test would require the anonymous user
to have list permissions on whatever resource was under test, requiring
a lot of role and grant and principal finagling. This is probably a good
longer-term TODO but not one that seemed worth it for this fix.
Fixes ICU-2301
This moves the generated pb files to the `sdk` module. This allows third parties to make use of them if desired (e.g. in upcoming plugins) and moves away from the `gen` nomenclature in the directory, since we are going to be adding some extra interface functions to the messages.
* add new error funcs which take a ctx and deprecate existing funcs
* use context where available when writing error events
* remove circular internal/errors pkg dep
* suppress some chatty errors using errors.WithoutEvent()
* convert auth oidc funcs to take context where needed to write events
Co-authored-by: Jim <jlambert@hashicorp.com>
The definition of 'subtype' is 'a secondary or subordinate type'. The
'T' should not be capitalized (unless it is referring to a type of
submarine, which its not).
Because of listing visibility, if no actions are assigned to a user for
an individual resource, it's excluded from the list. This is fine and
good. However, when we made a change in 0.2.0 to restrict the
information returned from listing for the anonymous user for scopes and
auth methods, it exposed the fact that because of the way this
visibility works we had to add `read` to scopes by default -- thereby
rather defeating the purpose of restricting what goes back to `u_anon`
requests.
The purpose of "no-op" is to never be used for real actions within the
API, but as something that can be granted to specifically enable
visibility for the targeted user. This makes the controls over list
visibility much more granular.
When using a disabled verifier context we were faking scope information. Due to other recent changes, this was now causing test errors. This adjusts that flow to actually query the DB, fixing tests and making them more like real code.
Current behavior is that you need list grant on the parent scope when
recursively listing, and this is sufficient. This is good for
administrative workflows but can be unintuitive for resources that only
exist at a project level. This change allows permissions on the child
scope to also be taken into account, so that you can start a recursive
list from a parent scope without direct list support on that scope but
still get back child scopes for which list access is granted.
This also fixes a bug where visibility of a scope for recursive listing
would be based on whether the user had list resources for roles within
that scope instead of for the resource type in question.
* 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.
* 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
Jim
Thor
Timothy Messier
Jeff Mitchell
s-christoffandJim
Todd Knight
Michael Gaffney
Louis Ruch