-
Epic
-
Resolution: Done
-
Major
-
None
-
Expand Fluentd Auth Capabilities
-
6
-
False
-
False
-
NEW
-
Done
-
NEW
-
0% To Do, 0% In Progress, 100% Done
-
Undefined
Story
As an administrator of Log Forwarding,
I want to configure outputs to use authorization credentials I supply
so that I am not forced to use mutual auth
Acceptance Criteria
- Documented supported authorization keys
- Recognized keys are added to an output's generated authorization configuration
Notes
- Currently all outputs are explicitly required to define all tls keys which locks them into mutual authentication
- By making keys optional, we can use the absence/presence of keys to enable all levels of TLS authentication, see below.
- Authorization configuration is added as-is. There is no implication we will try to verify a mismatch between authorization combinations
- We can identify structurally invalid combinations (e.g. password with no username) but we will not attempt to validate values, e.g. is a SASL mecanism supported or not?
Example for TLS configuration:
- URL scheme:
- If it is a secure scheme (https, tls etc.) then TLS is enabled. If there are no cert keys in the secret then this is standard browser-style TLS with server authenticated against the system's default CA.
- If it is an insecure scheme (http, udp etc.) then it is an error to have any TLS-releated keys in the secret. We want to avoid accidental clear-text connections due to configuration mistakes. There may still be a secret with other, non-TLS keys, e.g. username/password, if those are relevant to the output type.
- Secret keys
- tls.crt, tls.key: if present enable client auth - aka mTLS since we always enable server auth on any TLS connection.
- ca-bundle.crt: if present use this instead of the default system CA to authenticate the server.
- username/password: If present, and the output type has a username/password mode, then enable it. Not all output types will, it should be an error to specify username/password for an output type that doesn't use it.
- other: it's possible we will introduce other keys in future for new output types but we should try to keep the set small and broadly applicable.
This scheme can be extended with SASL keys and others (e.g. passphrase)
Impl. Questions
- Can/Should we add an authscheme field to output type (defaults to mutual) to assist us in determining what keys to use from the secret?
- is documented by
-
RHDEVDOCS-3121 Relax Authorization Requirements for Log Forwarding
- Closed