Description of problem: The customer needs a more secure environment and his security tools identified that's possible to know the version of Openshift, kubernetes, git release and other informations without proper authentication Version-Release number of selected component (if applicable): 3.11.x How reproducible: All times Steps to Reproduce: 1. Log on web-console and https://<publicURL>/console/about 2. curl -v -i https://console.shinra.inc/version -k Actual results: 1. Versions shown in the about page 2. curl -v -i https://console.example.com/version -k * Trying 192.168.123.3... * TCP_NODELAY set * Connected to console.example.com (192.168.123.3) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Request CERT (13): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Certificate (11): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305 * ALPN, server accepted to use h2 * Server certificate: * subject: C=JP; ST=Kanto; O=Example.com; CN=*.example.com * start date: Jun 19 19:38:15 2019 GMT * expire date: Oct 31 19:38:15 2020 GMT * issuer: C=JP; ST=Kanto; O=Example Com; OU=R&D; emailAddress=xxx * SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway. * Using HTTP2, server supports multi-use * Connection state changed (HTTP/2 confirmed) * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0 * Using Stream ID: 1 (easy handle 0x55df69fb67c0) > GET /version HTTP/2 > Host: console.example.com > User-Agent: curl/7.64.0 > Accept: */* > * Connection state changed (MAX_CONCURRENT_STREAMS == 250)! < HTTP/2 200 HTTP/2 200 < audit-id: 51087a3e-2891-48d3-9c26-523c9316eb23 audit-id: 51087a3e-2891-48d3-9c26-523c9316eb23 < cache-control: no-store cache-control: no-store < content-type: application/json content-type: application/json < content-length: 239 content-length: 239 < date: Fri, 12 Jul 2019 21:01:48 GMT date: Fri, 12 Jul 2019 21:01:48 GMT < { "major": "1", "minor": "11+", "gitVersion": "v1.11.0+d4cacc0", "gitCommit": "d4cacc0", "gitTreeState": "clean", "buildDate": "2019-06-09T23:23:08Z", "goVersion": "go1.10.8", "compiler": "gc", "platform": "linux/amd64" * Connection #0 to host console.shinra.inc left intact } Expected results: Not sensible information displayed Additional info: The customer needs a highly secured environment and any information leak that could lead to an exploiting or even an invasion it's a big concern. I'd like to know if there's any plans to review this decision and/or a roadmap to implemented. The customer needs at least an expected timeframe to move on with implementation project.
The following RFE has been created: https://jira.coreos.com/browse/RFE-249 I think we can close this bug and follows this via the above RFE.
Closed as this continuous to live in https://jira.coreos.com/browse/RFE-249.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days