[CLI] Require explicit CA for remote Python REST connections

[ashutosh-agrawal]

Why

The Python CLI actioner may connect to either the default local REST server or a configured remote endpoint. Remote connections should use a CA certificate selected specifically for that REST server while preserving the existing local workflow.

What

• Require REST_API_CA_CERT to identify a readable PEM CA certificate file for every non-loopback REST endpoint.
• Pass the configured CA path directly to Requests without falling back to Requests-specific or system CA bundles.
• Preserve the current behavior for localhost, IPv4 loopback addresses (127.0.0.0/8), and IPv6 loopback (::1).
• Limit certificate-warning suppression to individual loopback requests.
• Document the remote endpoint configuration and add focused unit coverage.

How to verify

• python3 -m unittest discover -s CLI/tests -p 'test_*.py' -v — 7 tests passed.
• python3 -m py_compile CLI/actioner/cli_client.py CLI/tests/test_cli_client.py
• git diff --check origin/master...HEAD

VS validation on vlab-01:

1. Built target/debs/trixie/sonic-mgmt-framework_1.0-01_amd64.deb and installed it in the mgmt-framework container.
2. Confirmed the default loopback REST endpoint remained reachable.
3. Confirmed that setting only REQUESTS_CA_BUNDLE did not provide a fallback for a remote endpoint.
4. Confirmed that a missing or unreadable REST_API_CA_CERT was rejected before the request.
5. Configured REST_API_CA_CERT with the test endpoint's CA and confirmed that the request succeeded.

Results:

endpoint_classification=PASS
local_loopback_request=PASS status=404
requests_ca_bundle_fallback_rejected=PASS
invalid_explicit_ca_rejected=PASS
explicit_ca_accepted=PASS status=200

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[qiluo-msft]

The fix correctly moves away from verify=False for remote endpoints, but using verify=True
relies on whatever CA certificates happen to be present in the container's system store.
For a managed SONiC deployment this is fragile — the container may not carry the right
enterprise CA, and there's no explicit operator control over which CA is trusted.

Suggest adding a --rest-ca-cert CLI option (or a counterpart in the existing REST
client config) that accepts a PEM-format CA file, and using that path as the verify=
argument for remote requests:

verify = ca_cert_path if not _is_loopback_endpoint(url) else False

where ca_cert_path is the value of --rest-ca-cert. If a remote endpoint is configured
and no --rest-ca-cert is supplied, the client should fail with a clear error rather than
falling back to the system store.

This gives operators an explicit, visible CA provisioning step instead of implicit
system-bundle trust.

[ashutosh-agrawal]

@qiluo-msft Thanks. After looking further, I agree that falling back to the general system trust store does not provide REST-specific control over the trusted CA.

I propose splitting the work into focused changes. In this PR, I will update the Python actioner client to require an explicitly configured CA file for non-loopback REST_API_ROOT values, without falling back to the system trust store.

The CLI also has a C++ libcurl REST client used for authentication and token refresh. I will submit a follow-up PR applying the same explicit-CA behavior there. The operator-facing --rest-ca-cert option, including host-to-container certificate provisioning, can then be added separately in sonic-buildimage.

Would this staged approach work for you?

[ashutosh-agrawal]

Updated in f0e11c8. The Python actioner now requires REST_API_CA_CERT for non-loopback endpoints and passes that PEM path directly to Requests. It does not fall back to REQUESTS_CA_BUNDLE or the system CA store, and missing or unreadable configuration returns a clear error before making the request.

I added focused unit coverage and repeated the VS validation. The configured explicit CA succeeded, while the Requests bundle fallback and an invalid explicit path were rejected. The C++ client and operator-facing CLI plumbing remain scoped to the follow-up changes described above.

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).