ZSS APIML static definition has hardcoded https scheme

[skurnevich]

Describe the bug

ZSS APIML static definition has hardcoded https scheme which is not working in AT-TLS setup

Steps to Reproduce

Run Zowe in AT-TLS configuration Try to use ZSS through the gateway - endpoints are not accessible. Manually create new static definition with HTTP scheme endpoints to verify it is working.

zOSMF static definition could be used for reference - https://github.com/zowe/api-layer/blob/v2.x.x/discovery-package/src/main/resources/zosmf-static-definition.yaml.template

[JoeNemo]

Sean is investigating

[1000TurquoisePogs]

Okay, I've confirmed that yes, you can configure AT-TLS in a way that would have the gateway see zss as https, therefore the hardcoding of https here is not an issue for that scenario.

But, if you've configured AT-TLS another way, as you did, then the gateway would see zss as http, and then you have the problem you describe.

Take for example this rule: https://docs.zowe.org/stable/user-guide/mvd-configuration#defining-the-at-tls-rule

https://www.ibm.com/docs/en/zos/2.5.0?topic=statements-ttlsrule-statement

TTLSRule                          ATTLS1~ZSS
{
  LocalAddr                       All/someIp/someIpRange
  RemoteAddr                      All/someIp/someIpRange
  LocalPortRange                  [zss_port]
  Direction                       Inbound/Outbound/Both
...
}

When you remove HTTPS from ZSS in order to use AT-TLS, whether or not a connection to ZSS sees HTTPS or HTTP depends upon the values above. For example, if LocalAddr or RemoteAddr were not All, then some connections would see HTTPS and others would see HTTP.

I asked others why would you ever want connections to become UNENCRYPTED versus what we do in Zowe today where everything is HTTPS all the time.

The only reason I heard was performance/resources, as TLS isn't free. But it'd come at the cost of reducing our security.

Consider client certificates. I believe discovery/gateway/caching-service can offer additional security depending on which certificate is seen. In the case of the caching-service for example, I believe it provides a key-value store that is scoped to the client certificate given, so that server A cannot read server B's storage.

If you turn off HTTPS, you lose this ability.

[1000TurquoisePogs]

As I asked around I also drew attention from product teams... they're telling me if ZSS weren't HTTPS from their servers perspective, it would be broken because they rely on those client certs

[skurnevich]

Ok, the conclusion is that users should always prefer using ZSS in HTTPS with the different AT-TLS rule. Should we keep this issue with low priority to cover the other use case, or just close it?