This is a bit of a guess given the lack of detail, however, it is increasingly common for services to store their credentials in CredHub instead of having them in Cloud Controller. This results in seeing a placeholder entry in VCAP_SERVICES
if you look at the environment variables as suggested in the comments.
If that is what you're seeing, you need to go one step further to retrieve the credentials (which is the exact point of the service doing this, it makes it harder to compromise a service's credentials).
cf ssh
into your app container
- Run
curl -vv -i -H 'Content-Type: application/json' --cert /etc/cf-instance-credentials/instance.crt --key /etc/cf-instance-credentials/instance.key -d "$VCAP_SERVICES" 'https://credhub.service.cf.internal:8844/api/v1/interpolate' | jq .
This may seem like magic, so I'll break it down.
a.) It's using curl
to query the /api/v1/interpolate
endpoint of CredHub. This API takes in the contents of VCAP_SERVICES
with placeholders and returns a version without placeholders.
b.) -d "$VCAP_SERVICES"
will set the body of the request to the contents of $VCAP_SERVICES
. This is exactly what the API call expects.
c.) You are telling curl
to perform mutual TLS using the cert & keys at /etc/cf-instance/credentials.key
& /etc/cf-instance/credentials.crt
. This allows you to authenticate with Credhub.
d.) The result is JSON, so jq .
just pretty-prints the response. It's optional.
You could implement the same in your programming language of choice using an HTTP client configured in the same way. You must do this from inside the container though, because CredHub is only available from there and also because that's the only place where you can get the cert/key required to authenticate to CredHub.