This updates the target resources to use a oneof for attributes. This
allows requests to the targets service to leverage the new
subtypes.AttributeTransformerInterceptor so that attributes are strongly
typed prior to the service handler.
The new `subtype.AttributeTransformerInterceptor` can return an error if
it fails to transform the attributes. This is mainly if invalid
attribute fields were included for a particular subtype. This error case
used to be checked in the grpc service handler functions. However, now
that it is happening in the interceptor, the `errorInterceptor` needs to
be moved up in the stack so that it will process the response of the new
transformation interceptor.
The `errorInterceptor` used to be after the `auditRequestInterceptor`
and prior to the `auditResponseInterceptor`, meaning that the
`auditResponseInterceptor` would have access to the result of the
`errorInterceptor`. But it seems the `auditRequestInterceptor` does not
use or need any of the headers set by the `errorInterceptor` so it
should be safe to move the `errorInterceptor`. This is important since
the `subtype.AttributeTransformerInterceptor` needs to be before the
audit interceptors in the stack to properly transform requests/responses
so they can be audited with the complete classification information.
This updates the credential store resources to use a oneof for
attributes. This allows requests to the credential store service to
leverage the new subtypes.AttributeTransformerInterceptor so that
attributes are strongly typed prior to the service handler.
This updates the credential library resources to use a oneof for
attributes. This allows requests to the credential library service to
leverage the new subtypes.AttributeTransformerInterceptor so that
attributes are strongly typed prior to the service handler.
This updates the credential store resources to use a oneof for
attributes. This allows requests to the credential store service to
leverage the new subtypes.AttributeTransformerInterceptor so that
attributes are strongly typed prior to the service handler.
The original idea was for these methods to eventually become
entirely encapsulated by the subtype package, but as it turns
out we still have use for them in custom transformation functions,
so move the subtype package to use these shared functions
instead.
This allows the user to register a custom transformation callback
for a specific protobuf message, in cases where the transformation
is sufficiently complex for it to be cumbersome to formalise
the logic through protobuf options.
This return value is just a reference to the input, which
is being mutated. We may as well make that clear via
the signature, which will also simplify the new custom
transformation function registration logic.
It is not unreasonable for downstream users of the request and response
messages to mutate them, indeed we mutate the response
on the way out to get the desired external API. To avoid
inconsistent messages being audited, make a copy of the
entire message before returning from the interceptor.
This was discovered while testing the new subtype transformation
interceptor.
This interceptor is responsible for maintaining compatability with the
JSON API with the change to the protobuf messages. The messages are
changing from a single attribue field to a oneof to explicitly associate
subtype attribute messages with the resource message. The interceptor
transforms the request prior to the auditReqeust interceptor, and
transforms the response after the auditResponse interceptor. This allows
the audit interceptors to use all the necessary classification
information when creating the audit events.
This allows for marking a field in a message as an id that can be used
to determine the message's subtype. When creating some resources, an id
from a related resource is used to indicate the resource's subtype,
since the resource must have the same subtype as the related resource.
This allows for associating all of the messages in a file with a domain.
This will be used by the global subtype registry to group subtypes
within a domain. When registering a subtype, it must be unique within a
domain. This allows for cases where two domains have the same subtypes,
such as two domains both having a "plugin" subtype.
These github actions run on Ubuntu based machine. Ubuntu by default
links `/bin/sh` to dash. So by invoking the plugin.sh script as `/bin/sh
./plugins.sh` the script would run under `dash` despite the shebang
line. A recent change that unified some of the build process, introduced
additional bashisms into this script which is caused the build to fail.
This updated the build system to just run the script directly, which
will honor the shebang line. This seems like the best approach since the
ubuntu machine has bash and the shebang line points to bash, so it is
natural for developers to assume bashisms will work.
See:
f370abc1dahttps://github.com/actions/virtual-environments/blob/ubuntu20/20220410.2/images/linux/Ubuntu2004-Readme.mdhttps://wiki.ubuntu.com/DashAsBinSh
Other parts of the system make use of a "type" field, while the
AuthenticateResponse sets a "token_type" on the response attributes
directly. Rename this field to "type", and move it up to the response
level, to be more consistent with other RPCs.
Also adds a new field to the AuthenticateRequest, "type" which will
replace the "token_type" field over time.
This reduces the chance that we'll hit a failure due to a mismatched
worker address, on the certificate, especially if a worker has multiple
addresses. We aren't relying on IP/DNS for security anyways, so let's
not have it be a hindrance.
Timothy Messier
Johan Brandhorst-Satzkorn
irenarindos
Zed
Jim
Jeff Mitchell