The wrapper is sometimes unset at the time when the
audit config is validated, so it is impossible for us
to validate that a valid wrapper is configured. The wrapper
is configured by later setup steps because of a dependency
on the eventer in our KMS setup.
Classify fields for all api and cluster protobuf messages.
Before classification, audit events would be completely redacted.
Now events will contain unredacted values according to classification.
Audit events are now no longer considered a WIP.
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.