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

Allow to set username / password for external ElasticSearch output inside the LF API



    • Basic authentication against external Elasticsearch
    • False
    • False
    • NEW
    • Done
    • NEW
    • 85
    • 85% 85%
    • Undefined
    • 3
    • High (80-100%) - [We are confident it will become an issue]
    • Low



      • Provide an option for a user to set the username and password for external ElasticSearch instances via a `Secret` or similar.




      Currently, the Log Forwarding (LF) API support forwarding logs to an external Elasticsearch by either a secure mTLS or insecure (just `http`) connection. Although we recommend using mTLS, we have customers that do not have the power to change the external Elasticsearch cluster since it may be owned by someone else. Additionally, Elastic.co and also AWS Elasticsearch does not provide any mechanism to connect via TLS either and only provide an API for username/password.


      The current workaround is to manually specify the username and password in a secure-forward.conf without using the ClusterLogForwarder CRD. See RFE-810 for more details. Obviously, this involves using the legacy configuration method which will be removed in a future version of Logging.

      Risk and Assumptions


      Acceptance Criteria

      • Verify that you can configure username/password for authenticating again an external ES instance and send logs either via HTTP or HTTPs.
      • Elasticsearch supports HTTP with username/password OR HTTPS with tls.key and tls.cert

      Documentation Considerations

      • Add information to the existing ES forwarding topic on how to configure username/password inside the Log Forwarding API to forward logs to an external Elasticsearch instance.
        • We should add information on how to create a Secret, what fields inside the Secret are possible, and how to configure basic auth with either HTTP or HTTPs.
      • I saw that we have existing documentation for what fields are possible in the Secret and we need to adjust that since now, you are able to define username and password as additional fields. In that same sentence, we should also remove the "MUST" keyword since now you have some choice, so maybe we can reframe this a little bit and only talk about the possible fields and when they are important.


        Issue Links


            Public project attachment banner

              context keys: [headless, issue, helper, isAsynchronousRequest, project, action, user]
              current Project key: LOG


                ikarpukh Igor Karpukhin (Inactive)
                cvogel1 Christian Heidenreich (Inactive)
                Qiaoling Tang Qiaoling Tang
                6 Vote for this issue
                19 Start watching this issue