CLI and Secret Substitution

[manderson23]

I'm investigating secret substitution with the CLI but something isn't working correctly.

I'm running msb as follows

msb run -n sandbox-test --replace \
 --secret "USER='$USER'@service.my.internal.host" \
 --secret "PASSWORD='$PASSWORD'@service.my.internal.host" \
 --net-rule "allow@public,allow@private" --no-dns-rebind-protection --trust-host-cas --tls-intercept \
 --volume $(pwd):/workspace --workdir /workspace \
 my.internal.registry/ubi-minimal:9.7-1773939694 -- ./run.sh

where run.sh attempts to use the username and password secrets in curl with HTTP basic auth

HOST_ENTRY="10.227.23.116 service.my.internal.host"
grep -qxF "$HOST_ENTRY" /etc/hosts || echo "$HOST_ENTRY" >> /etc/hosts

curl -v -u "${USER}:${PASSWORD}" https://service.my.internal.host

In the curl output I see Server auth using Basic with user '$MSB_USER' and the Basic Auth header is Authorization: Basic JE1TQl9VU0VSOiRNU0JfUEFTU1dPUkQ= which decodes as $MSB_USER:$MSB_PASSWORD

I expected the secret values to be substituted in.

Am I missing something in my command or understanding of how secret substitution works?

[toksdotdev]

this is likely related to #646. secret substitution isn't supported for plain http. should be trivial to support. i'll look into it later today.

workaround:

• configure your service to speak tls, or
• put the service behind a proxy that speaks tls e.g. caddy, nginx, etc.

[manderson23]

Thanks.

As a related question does substitution work with bearer tokens? e.g. Authorization: Bearer $TOKEN

[toksdotdev]

yes, it does today.

[manderson23]

Using the workaround doesn't solve the issue with the current version for either basic auth or bearer token.

In the curl verbose output I see Authorization: Basic $MSB_BASIC_AUTH or Authorization: Bearer $MSB_TOKEN so the values aren't substituted.

Will #702 solve this? I also see #703 was created.

[manderson23]

And as a follow up question that might impact the above - HTTPS_PROXY is set to use a corporate proxy for the curl request.

HTTPS_PROXY=http://proxy.corporate.com:80

and in curl you see

Connected to proxy.corporate.com (10.x.y.z) port 80 (#0)
* allocate connect buffer!
* Establish HTTP proxy tunnel to internal.host.com:443
> CONNECT  internal.host.com:443 HTTP/1.1
> Host:  internal.host.com:443

Would that have any impact on how TLS interception and secret substitution operate?

[manderson23]

OK I've now noticed in the logs that there is no DEBUG microsandbox_network::tls::proxy: TLS intercept entry when using the proxy - I assume because it is http:// ?

Would this be resolved by #646 ?

[manderson23]

Closing as #752 has been opened.