Hint to display service binding credentials

[gberche-orange]

Stratos Version

What version of Stratos does this related to? 4.4.0-defcc460f-cap

Detailed Description

As a CF developer

• in order to troubleshoot access to a service instance bound to my application
• I need a way to display the service binding credentials

Currently, the environment page does not include the VCAP_SERVICES nor VCAP_APPLICATION environment variables (unlike the CF-CLI)

Output of CF CLI v7

$ cf env backend-service-bindings
Getting env variables for app backend-service-bindings in org acdc-demo-iaas-consumption-sosh-care / space backend as gberche...
System-Provided:
VCAP_SERVICES: {
"p-mysql": [
{
"binding_name": null,
"credentials": {
"hostname": "192.168.30.150",
"jdbcUrl": "jdbc:mysql://192.168.30.150:3306/cf_4e2accf3_823b_4f07_99d0_f4560fef63ec?user=l1bOKPdlZWq1OibN\u0026password=redacted",
"name": "cf_4e2accf3_823b_4f07_99d0_f4560fef63ec",
"password": "redacted",
"port": 3306,
"uri": "mysql://l1bOKPdlZWq1OibN:redacted@192.168.30.150:3306/cf_4e2accf3_823b_4f07_99d0_f4560fef63ec?reconnect=true",
"username": "l1bOKPdlZWq1OibN"
},
"instance_name": "backend-db",
"label": "p-mysql",
"name": "backend-db",
"plan": "1gb",
"provider": null,
"syslog_drain_url": null,
"tags": [
"mysql"
],
"volume_mounts": []
}
]
}

VCAP_APPLICATION: {
...
}

No user-provided env variables have been set

No running env variables have been set

Staging Environment Variable Groups:
http_proxy: http://system-internet-http-proxy.internal.paas:3128
https_proxy: http://system-internet-http-proxy.internal.paas:3128

Associated CC API V3 calls in CF CLI V7, the envs are formatted in the GET /v3/apps/:guid/env endpoint

$ CF_TRACE=true cf env backend-service-bindings | grep 'GET '
GET / HTTP/1.1
GET /v3 HTTP/1.1
GET /login HTTP/1.1
GET /v3/apps?names=backend-service-bindings&space_guids=cfb23f5a-44ed-4f60-add5-5545ed78f4a3 HTTP/1.1
GET /v3/apps/10e8f16d-bce2-497a-996c-0f984251eeb1/env HTTP/1.1

Similar with cf v6 and V2 APIs:

$ CF_TRACE=true cf env backend-service-bindings | grep 'GET '
GET /v2/spaces/cfb23f5a-44ed-4f60-add5-5545ed78f4a3/apps?q=name%3Abackend-service-bindings&inline-relations-depth=1 HTTP/1.1
GET /v2/apps/10e8f16d-bce2-497a-996c-0f984251eeb1/env HTTP/1.1

Context

Why is this change important to you? How would you use it? How can it benefit other users?

This feature is a potential workaround for lack of support of service keys (which is detailed in https://github.com/cloudfoundry/stratos/issues/3487 )

Possible Implementation

[gberche-orange]

The binding credentials are actually available in the card view of the app services:

Maybe a hint such as looking for VCAP_SERVICES env var ? Find them in the [services view](/applications/-o1F0L956QhAIK7R56Uc1lMh5L4/<app-guid>/services) should help users most familliar with CF CLI UX

I'm therefore renaming this issue

[richard-cox]

This could be a v2/v3 api issue, from memory those fields should show. Could you confirm you're seeing the same with an app pushed via cf cli 6?

[gberche-orange]

Thanks @richard-cox for your response. Indeed, an app pushed with cf cli v6 displays its env var correctly in stratos. Pretty weird.

$ cf -v
cf version 6.52.0+b086fe522.2020-08-26

$ cf push backend-service-bindings-cf6 -b staticfile_buildpack -m 32M
[...]
$ cf bs backend-service-bindings-cf6 backend-db
[...]
$ cf env backend-service-bindings-cf6 backend-db
# VCAP_SERVICES also properly displayed

Strangely the env vars properly display with cf env cli command in both v6 and v7 versions. Here are the corresponding API calls made by each version

$ switch-cf7 
which cf:
lrwxrwxrwx 1 root root 12 févr. 15 18:25 /usr/bin/cf -> /usr/bin/cf7
cf version 7.1.0+4c3168f9a.2020-09-09

$ CF_TRACE=true cf env backend-service-bindings-cf6  | grep 'GET '
GET / HTTP/1.1
GET /v3 HTTP/1.1
GET /login HTTP/1.1
GET /v3/apps?names=backend-service-bindings-cf6&space_guids=cfb23f5a-44ed-4f60-add5-5545ed78f4a3 HTTP/1.1
GET /v3/apps/8bed141f-0ec3-4a48-88f9-4a1f237c7198/env HTTP/1.1

$ switch-cf6
which cf:
lrwxrwxrwx 1 root root 12 févr. 15 18:25 /usr/bin/cf -> /usr/bin/cf6
cf version 6.52.0+b086fe522.2020-08-26

$ CF_TRACE=true cf env backend-service-bindings-cf6  | grep 'GET '
GET /v2/spaces/cfb23f5a-44ed-4f60-add5-5545ed78f4a3/apps?q=name%3Abackend-service-bindings-cf6&inline-relations-depth=1 HTTP/1.1
GET /v2/apps/8bed141f-0ec3-4a48-88f9-4a1f237c7198/env HTTP/1.1

With an app pushed with cf v7 (and which stratos does not display VCAP_SERVICES), stratos makes the following API call to stratos backend : GET | https://stratos.redacted-domain.org/pp/v1/proxy/v2/apps/10e8f16d-bce2-497a-996c-0f984251eeb1/env?order-direction=desc&order-direction-field=name&results-per-page=5&page=1

Is there an easy way to track down the corresponding stratos backend call made to CF CC API ?

[richard-cox]

Stratos will directly proxy those types of request to the CF, in this case it's still going out to the v2 endpoint apps/10e8f16d-bce2-497a-996c-0f984251eeb1/env. Perhaps the issue is due to a difference in format of the response, do you have a copy of the raw results of calling v2/ ... /env on a cli6 deployed app and a similar cli7 deployed app?

[gberche-orange]

The main difference I can spot is the environment_json being empty (app provisionned by v3/cf7) or null (app provisionned by v2/cf6). I'm sending you the cf6-app-env.json cf7-app-env.json files privately.

CF_TRACE=true cf env backend-service-bindings | grep 'GET '
cf curl /v2/apps/10e8f16d-bce2-497a-996c-0f984251eeb1/env > cf6-app-env.json
CF_TRACE=true cf env backend-service-bindings-cf6 | grep 'GET '
cf curl /v2/apps/8bed141f-0ec3-4a48-88f9-4a1f237c7198/env > cf7-app-env.json

diff  cf6-app-env.json cf7-app-env.json 
7c7
<    "environment_json": null,
---
>    "environment_json": {},