Bug 1729610 - remove version information from web-console and API
Summary: remove version information from web-console and API
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: kube-apiserver
Version: 3.11.0
Hardware: All
OS: Linux
low
urgent
Target Milestone: ---
: 3.11.z
Assignee: Stefan Schimanski
QA Contact: Xingxing Xia
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-07-12 21:07 UTC by Miguel Figueiredo Nunes
Modified: 2023-09-14 05:31 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-05-20 08:14:59 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1437573 0 unspecified CLOSED [RFE] openshift and kubernetes versions available before authenticed at console/config.js 2021-07-19 15:40:31 UTC

Description Miguel Figueiredo Nunes 2019-07-12 21:07:20 UTC
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.

Comment 13 Ryan Howe 2019-07-30 20:01:42 UTC
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.

Comment 16 Stefan Schimanski 2020-05-20 08:14:59 UTC
Closed as this continuous to live in https://jira.coreos.com/browse/RFE-249.

Comment 17 Red Hat Bugzilla 2023-09-14 05:31:49 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days


Note You need to log in before you can comment on or make changes to this bug.