[SURE-11453] Fleet OCI storage ignores insecureSkipTLS and fails with x509 unknown authority in downstream fleet-agent

[khushalchandak17]

Rancher Server Setup

• Rancher version: v2.13.3
• Installation option (Docker install/Helm Chart):
  • If Helm Chart, Kubernetes Cluster and version (RKE1, RKE2, k3s, EKS, etc):
• Proxy/Cert Details:
  • Rancher, Harbor/internal registry are using SSL certificates signed by a self-signed/private CA

Information about the Cluster

• Kubernetes version:
  • Local cluster: RKE2 v1.34.3
  • Downstream cluster: RKE2 v1.34.4
  • Registry cluster: K3s v1.34.4
• Cluster Type (Local/Downstream):
  • Local cluster: Rancher local cluster
  • Downstream cluster: Downstream Custom or Imported

User Information

• What is the role of the user logged in? (Admin/Cluster Owner/Cluster Member/Project Owner/Project Member/Custom)
  • Admin
  • If custom, define the set of permissions:

Describe the bug
Fleet OCI storage does not appear to honor insecureSkipTLS: true when this value is provided in the OCI storage secret.

In our setup, the downstream fleet-agent fails to fetch OCI content from an internal registry that uses a certificate signed by a self-signed/private CA, even though insecureSkipTLS: true is set in the secret.

The downstream agent still performs normal TLS verification and fails with:

Failed to perform "FetchReference" on source:
Get "https://registry01.example.internal:443/v2/ocistorage/s-<hash>/manifests/latest":
tls: failed to verify certificate: x509: certificate signed by unknown authority

To Reproduce

1. Set up Rancher v2.13.3 with Fleet.
2. Create or use a downstream cluster managed by Fleet.
3. Configure an internal OCI registry with a certificate signed by a self-signed/private CA.
4. Create an OCI storage secret using insecureSkipTLS: true.
5. Configure Fleet to fetch OCI content using that secret.
6. Observe the downstream fleet-agent logs while it attempts to fetch the OCI reference.

Result
The downstream fleet-agent fails with x509: certificate signed by unknown authority, indicating that TLS verification is still being performed.

Expected Result
When insecureSkipTLS: true is set in the OCI storage secret, Fleet should pass that behavior through correctly and the downstream fleet-agent should skip TLS verification for the OCI registry fetch.

Screenshots
N/A

Additional context

• The issue seems related to OCI secret parsing, specifically around the field name used for the insecure TLS setting.
• A useful validation step is to compare behavior between:
  • insecureSkipTLS: true
  • insecure: true
• Internal reference: SURE-11440