ft: Remove insecure SSL context creation in Triton Python backend

[pravali96]

Issue #, if available: https://t.corp.amazon.com/P346071810

Summary of Changes

This PR removes the following line from triton_python_backend_utils.py:
ssl._create_default_https_context = ssl._create_unverified_context

Reason for Change

This line globally disabled SSL certificate verification for the Python process.

• Vulnerability: It exposed the container to Man-in-the-Middle (MITM) attacks by allowing connections to servers with invalid or self-signed certificates.
• Technical Debt: It masked potential environment configuration issues (missing CA certs) rather than solving them.

Risk Assessment & Verification

I performed a two-step verification to ensure removing this line does not cause regressions for users downloading models or artifacts at runtime.

1. Functional Regression Test

• Test: Deployed a ResNet50 model using ModelBuilder with the Triton backend.
• Result: The model initialized and performed inference correctly without the SSL bypass.

2. Environment Network Security Test

• Objective: Verify that the underlying Docker image (sagemaker-tritonserver:23.02-py3-cpu) has valid Root CA certificates installed and can perform a standard SSL handshake.
• Method: Executed a direct network call inside the container using urllib without the insecure bypass.
• Command:
  docker run --rm --entrypoint python3 <IMAGE_URI> -c "import urllib.request; print(urllib.request.urlopen('https://www.python.org').getcode())"
• Output:

  TESTING SSL CONNECTIVITY IN CONTAINER...
  Attempting to connect to python.org...
  SUCCESS: Connected with HTTP 200
  SSL Certificates are present.
  

Conclusion

The base image correctly handles SSL verification. The insecure workaround is redundant and unsafe, and has been removed.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.