want `triton profile create --insecure` to be able to setup a profile to a cloudapi with self-signed cert

[trentm]

E.g. for dev/testing DCs. Also docs around insecure:true.

[papertigers]

+1

[sts]

triton 4.13.0 - currently looks like it fails, while checking for an available docker service api.

# triton -i profile create
A profile name. A short string to identify a CloudAPI endpoint to the
`triton` CLI.
name: test

The CloudAPI endpoint URL.
url: https://10.10.150.13

Your account login name.
account: tester

The fingerprint of the SSH key you have registered for your account.
Alternatively, You may enter a local path to a public or private SSH key to
have the fingerprint calculated for you.
keyId: ~/.ssh/id_rsa
Fingerprint: fe:35:f8:dd:0b:2a:ba:1a:b7:85:a1:2a:4c:cc:e3:1b

Saved profile "test".
Warning: Error determining if CloudAPI "https://10.10.150.13" provides a Docker service:
    SetupError: error pinging CloudAPI <https://10.10.150.13>: self signed certificate

[misterbisson]

There was some question about how this works with Docker as well (triton env can set Docker env vars, see https://github.com/joyent/node-triton/issues/46).

Assuming the --insecure arg proposed here would automate the process of adding "insecure": true, to the profile in ~/.triton/profiles.d/<profile name>.json as below:

{
    "account": "<account name>",
    "insecure": true,
    "url": "https://<cloud API endpoint with self-signed cert>",
    "keyId": "SHA256:<key fingerprint>"
}

...then the Docker configuration should work as expected.

The manual steps of adding "insecure": true,, then running triton profile docker-setup <profile with self-signed cert> work.

From that point, do a eval $(triton env <profile with self-signed cert) and then try a Docker command like docker run --rm -it holzi/quine-relay and you'll see it works.

[misterbisson]

Correction:

My note above included the use of eval $(triton env <profile with self-signed cert), which is sufficiently different from eval "$(triton env <profile with self-signed cert)". The export commands work in both cases, but without the quotes, unset DOCKER_TLS_VERIFY in eval $(triton env <profile with self-signed cert) doesn't get eval'd.

All that resulted in configuration leakage from other profiles that were setting DOCKER_TLS_VERIFY=1. That said, it appears that we should set DOCKER_TLS_VERIFY=1 even when "insecure": true.

[axisofentropy]

+1