tink-agent-setup fixes

[jacobbmay]

Description

• If registry credentials are provided, the tink-agent-setup script now performs a nerdctl login so the tink-agent image can be pulled from a registry requiring auth
• Allow configuring both http and https insecure registries instead of only http
  • Implementation is backwards compatible for actual http registries so an insecure http registry configured like example.your.domain would still be configured as an http registry, but explicitly setting https on the registry like https://example.your.domain will now configure it as an https registry that skips TLS verification

Fixes:
Currently tink-agent-setup doesn't authenticate with credentials provided so it doesn't work with registries requiring auth.

Also noticed that the current handling of insecure registries being passed in assumes they are all http registries but also sets skip_verify which is only relevant to https registries. nerdctl seems to see the tls related setting and attempts to use https first when pulling an image, but not when authenticating. So after adding the login command, authentication still wasn't working since I am testing with an https registry configured as insecure.

How Has This Been Tested?

Built with uv run ./build.py and then tested with QEMU using the following command:

uv run ./build.py qemu-test \
    --tink-worker-image baz.local/tink-agent:v0 \
    --tink-docker-registry baz.local \
    --tink-registry-username testuser \
    --tink-registry-password testpass-shell-validation \
    --tink-insecure-registries "foo.local,http://bar.local:5000,https://baz.local" \
    --qemu-append "systemd.journald.forward_to_console=1"

Validated that all 3 insecure registries were configured correctly to ensure both http and https insecure registries are handled as expected:

root@captainos:~# cat /etc/containerd/certs.d/bar.local\:5000/hosts.toml 
server = "http://bar.local:5000"

[host."http://bar.local:5000"]
  capabilities = ["pull", "resolve", "push"]
root@captainos:~# cat /etc/containerd/certs.d/baz.local/hosts.toml 
server = "https://baz.local"

[host."https://baz.local"]
  capabilities = ["pull", "resolve", "push"]
  skip_verify = true
root@captainos:~# cat /etc/containerd/certs.d/foo.local/hosts.toml 
server = "http://foo.local"

[host."http://foo.local"]
  capabilities = ["pull", "resolve", "push"]

Also verified that the login to baz.local was attempted using https (expected auth failure since the registry doesn't exist. Just validating it is using the correct scheme):

Jul 01 19:14:18 captainos tink-agent-setup[275]: {"time":"2026-07-01T19:14:18Z","level":"info","msg":"logging into registry","host":"baz.local"}
Jul 01 19:14:18 captainos tink-agent-setup[437]: time="2026-07-01T19:14:18Z" level=error msg="failed to call tryLoginWithRegHost" error="failed to call rh.Client.Do: Get \"https://baz.local/v2/\": dial tcp: lookup baz.local on 10.0.2.3:53: no such host" i=0

Next to validate auth to an http registry still uses the correct scheme, I tested with this command:

uv run ./build.py qemu-test \
    --tink-worker-image foo.local/tink-agent:v0 \
    --tink-docker-registry foo.local \
    --tink-registry-username testuser \
    --tink-registry-password testpass-shell-validation \
    --tink-insecure-registries "foo.local,http://bar.local:5000,https://baz.local" \
    --qemu-append "systemd.journald.forward_to_console=1"

And verified in journalctl the login related logs show the correct scheme for foo.local (again, expected failure but wanted to validated the scheme used for login):

Jul 01 19:21:57 captainos tink-agent-setup[277]: {"time":"2026-07-01T19:21:57Z","level":"info","msg":"logging into registry","host":"foo.local"}
Jul 01 19:21:57 captainos tink-agent-setup[439]: time="2026-07-01T19:21:57Z" level=error msg="failed to call tryLoginWithRegHost" error="failed to call rh.Client.Do: Get \"http://foo.local/v2/\": dial tcp: lookup foo.local on 10.0.2.3:53: no such host" i=0

How are existing users impacted? What migration steps/scripts do we need?

The tink-agent image can now be pulled from a registry requiring authentication and insecure TLS registries can be configured correctly.

Existing users configuring insecure http registries are unaffected since this change keeps the existing behavior of insecure registries not specifying a scheme defaulting to http.

Existing users configuring insecure https registries that don't require authentication will need to add the https:// scheme to the beginning of their insecure registry hostnames since this is no longer relying on nerdctl auto attempting https for image pulling.

Checklist:

I have:

• updated the documentation and/or roadmap (if required)
• added unit or e2e tests
• provided instructions on how to upgrade