feat(auth): implement auto-detection for k8s serviceaccount token

[andrewazores]

Fixes #382

Adds two new configuration properties: cryostat.agent.authorization.type and cryostat.agent.authorization.value.

The old cryostat.agent.authorization property is still present and takes precedence over the new properties.

In the old scheme, cryostat.agent.authorization was used by users to set values like Basic dXNlcjpwYXNz, where dXNlcjpwYXNz is the base64 encoded form of the string user:pass. The user could also set it to a value like Bearer sha256~ol7e1zOTvNrgAfwBM8cKcsI6eOatl_nUyXa8oGACGSA. These values would become an Authorization header that the Agent includes with all outoing HTTP requests that it makes to the Cryostat server it is configured to register with.

In the new scheme this is still supported, and if cryostat.agent.authorization is directly set in this way then the new .type and .value properties are ignored. If cryostat.agent.authorization is not set, the other two can be used to enable more convenient mechanisms for defining credentials:

cryostat.agent.authorization.type=basic + cryostat.agent.authorization.value=user:pass is equivalent to cryostat.agent.authorization=Basic dXNlcjpwYXNz. Notably, this way the user is not required to do the base64 encoding themselves.

cryostat.agent.authorization.type=bearer + cryostat.agent.authorization.value=sha256~ol7e1zOTvNrgAfwBM8cKcsI6eOatl_nUyXa8oGACGSA is equivalent to cryostat.agent.authorization=Bearer sha256~ol7e1zOTvNrgAfwBM8cKcsI6eOatl_nUyXa8oGACGSA.

cryostat.agent.authorization.type=kubernetes + cryostat.agent.authorization.value=/some/path/to/token can be used to have the Agent read /some/path/to/token to a String, then use the header value Bearer $token.

cryostat.agent.authorization.type=none explicitly disables the Authorization header from being sent (in the old scheme, it would always be sent but might include a blank or useless value).

cryostat.agent.authorization.type=auto will try to do Kubernetes detection, and if that fails (ex. the token file path is not an existing, readable, regular file), will disable the header from being sent.

The default values are auto, /var/run/secrets/kubernetes.io/serviceaccount/token, so that the Agent will try to detect if it is in a Kubernetes environment and present that token, or else send nothing. For most deployments this token has no useful permissions/roles by default, but it allows users to provide roles to their workload and have that enable the Agent to register with Cryostat directly, without the user needing to separately configure the credentials the Agent will present.

[andrewazores]

@ebaron what do you think of this? It's backward compatible and as I outline in the PR body, does not necessarily accomplish anything on its own. But I think it's a useful extension that can make things a bit simpler or clearer to configure.

@mwangggg you can hold off on reviewing this until after Elliott and I figure out if we'll bother trying to get this merged for this release cycle.

[ebaron]

This makes sense to me. I like that the path is configurable since I think we can mount a different service account token into a pod than the service account the pod runs as:
https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#serviceaccount-token-volume-projection. This might be useful if the user already has a service account for their workload that they don't want to modify.

[andrewazores]

@mwangggg could you take a look at this?

[mwangggg]

looks good to me!