Uploaded image for project: 'WildFly WIP'
  1. WildFly WIP
  2. WFWIP-315

XP OpenShift image http management interface secured with no user by default

    XMLWordPrintable

Details

    • Bug
    • Resolution: Not a Bug
    • Critical
    • OpenShift
    • None

    Description

      In one test with XP image [1] I am experiencing problem of failing rediness probe.

      sh-4.2$ python -d /opt/eap/bin/probes/runner.py --debug -c READY --loglevel=DEBUG probe.eap.dmr.EapProbe probe.eap.dmr.HealthCheckProbe
      DEBUG:__main__:Starting probe runner with args: Namespace(check=[<Status.READY: 8>], debug=True, logfile=None, loglevel='DEBUG', probes=['probe.eap.dmr.EapProbe', 'probe.eap.dmr.HealthCheckProbe'])
      INFO:__main__:Loading probe: probe.eap.dmr.EapProbe
      DEBUG:probe.eap.dmr.EapProbe:Configuration set as follows: host=localhost, port=9990, user=eapadmin, password=***
      INFO:__main__:Loading probe: probe.eap.dmr.HealthCheckProbe
      DEBUG:probe.eap.dmr.HealthCheckProbe:Configuration set as follows: host=localhost, port=9990, user=eapadmin, password=***
      INFO:__main__:Probes will fail for the following states: [HARD_FAILURE, FAILURE, NOT_READY]
      INFO:__main__:Running probes
      INFO:__main__.ProbeRunner:Running the following probes: [probe.eap.dmr.EapProbe, probe.eap.dmr.HealthCheckProbe]
      INFO:__main__.ProbeRunner:Running probe: probe.eap.dmr.EapProbe
      INFO:probe.eap.dmr.EapProbe:Executing the following tests: [probe.eap.dmr.ServerStatusTest, probe.eap.dmr.BootErrorsTest, probe.eap.dmr.DeploymentTest]
      INFO:probe.eap.dmr.EapProbe:Sending probe request to http://localhost:9990/management
      DEBUG:probe.eap.dmr.EapProbe:Probe request = {
          "operation": "composite",
          "json.pretty": 1,
          "steps": [
              {
                  "operation": "read-attribute",
                  "name": "server-state"
              },
              {
                  "operation": "read-boot-errors",
                  "address": {
                      "core-service": "management"
                  }
              },
              {
                  "operation": "read-attribute",
                  "name": "status",
                  "address": {
                      "deployment": "*"
                  }
              }
          ],
          "address": []
      }
      INFO:urllib3.connectionpool:Starting new HTTP connection (1): localhost
      DEBUG:urllib3.connectionpool:"POST /management HTTP/1.1" 403 188
      DEBUG:probe.eap.dmr.EapProbe:Probe response: <Response [403]>
      ERROR:probe.eap.dmr.EapProbe:Unexpected failure sending probe request
      Traceback (most recent call last):
        File "/s2i-output/server/bin/probes/probe/api.py", line 142, in execute
          results = self.sendRequest(request)
        File "/s2i-output/server/bin/probes/probe/dmr.py", line 97, in sendRequest
          self.failUnusableResponse(response, request, url)
        File "/s2i-output/server/bin/probes/probe/dmr.py", line 108, in failUnusableResponse
          unusable = not respDict or not respDict["outcome"] or respDict["outcome"] != "failed" or not respDict["result"]
      KeyError: 'result'
      INFO:__main__.ProbeRunner:Probe probe.eap.dmr.EapProbe returned statuses [FAILURE]
      DEBUG:__main__.ProbeRunner:Probe probe.eap.dmr.EapProbe returned messages "Error sending probe request: 'result'"
      

      Note there is Response [403] which makes me think it will be related with legacy security switch with Elytron.

      When I look at CD19 standalon-openshift.xml I see by default management interface is unsecured. Once ADMIN_PASSWORD, ADMIN_USERNAME is applied it is secured by legacy security ManagementRealm pointing to mgmt-users.properties

      In contrast in XP images it is secured by default by management-http-authentication which is pointing to mgmt-users.properties, which is empty by default. Once ADMIN_PASSWORD, ADMIN_USERNAME is applied it is filled with that user

              <management-interfaces>
                  <http-interface http-authentication-factory="management-http-authentication" console-enabled="false">
                      <http-upgrade enabled="true" sasl-authentication-factory="management-sasl-authentication"/>
                      <socket-binding http="management-http"/>
                  </http-interface>
              </management-interfaces>
      

      I think both approaches should be consistent (no matter if legacy or Elytron). E.g. unsecured by default and secured when ADMIN_PASSWORD, ADMIN_USERNAME specified (like in case of CD19)

      [1] docker-registry.upshift.redhat.com/kwills/eap-xp1-openjdk8-openshift-rhel7:EAP7-1484

      Attachments

        1. standalone-openshift.cd19.xml
          32 kB
          Martin Choma
        2. standalone-openshift.xp.xml
          24 kB
          Martin Choma

        Activity

          People

            jmesnil1@redhat.com Jeff Mesnil
            mchoma@redhat.com Martin Choma
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: