Uploaded image for project: 'OpenShift Logging'
  1. OpenShift Logging
  2. LOG-1468

Relax Authorization Requirements for Log Forwarding

    XMLWordPrintable

Details

    • Expand Fluentd Auth Capabilities
    • 6
    • False
    • False
    • NEW
    • Done
    • NEW
    • 100
    • 100% 100%
    • Undefined

    Description

      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?
         

      Attachments

        Issue Links

          Activity

            People

              rhn-engineering-aconway Alan Conway
              jcantril@redhat.com Jeffrey Cantrill
              Anping Li Anping Li
              Votes:
              1 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: