[kpstack]

Problem

Backend set SSL could reference a listener/secret cert, but there was no way to trust an OCI Certificates Service CA bundle on the backend set, and VerifyPeerCertificate was effectively fixed to false, so the LB never verified backend certificates. There was also no way to give the LB a readable display name.

What changed

Three Service annotations:

• oci.oraclecloud.com/oci-load-balancer-backendset-ca-bundle — attach a CA bundle OCID to the backend set SSL config.
• oci.oraclecloud.com/oci-load-balancer-verify-peer-certificate — enable backend peer verification (true/yes/1). When a CA bundle is set, verify-depth defaults to 1 to match the value OCI assigns, so reconciliation doesn't churn.
• oci.oraclecloud.com/oci-load-balancer-name — custom display-name prefix; the Service UID is appended (<name>-<uid>) and truncated to 1024 chars.

A CA bundle can now be supplied without oci-load-balancer-ssl-ports; the backend set SSL config is derived from the service ports.

Why

Verifying backends against a private CA is a common mTLS/zero-trust requirement, and CA bundles are the OCI-native way to express trust. Custom names make LBs identifiable in the console.

Compatibility

Additive and opt-in. With none of the annotations set, behavior is unchanged: no CA bundle, verify-peer=false, existing name scheme. verify-depth defaulting to 1 only applies when a CA bundle is present.

Validation

go test ./pkg/cloudprovider/providers/oci/ — new unit tests for name generation, verify-depth defaulting/drift, explicit-depth preservation, and CA-bundle-only SSL.

End-to-end on a live OKE cluster, a LoadBalancer Service produced an OCI LB with: custom name <name>-<uid>, flexible 10/10, backend set CA bundle attached, verify-depth=1, verify-peer-certificate=true; the config persisted across a controller restart + resync, and HTTP requests through the LB returned 200.

Note for maintainers

During validation, CreateLoadBalancer with a backend-set CA bundle (trustedCertificateAuthorityIds) consistently returned an opaque HTTP 500 when the request was signed by an Instance Principal, while a byte-identical request signed by a user principal succeeded. This was isolated from subnet, payload, IAM (reproduced with broad admin), tags, listener config, and controller concurrency — it correlates only with instance-principal auth + CA-bundle association. It's an OCI service-side behavior, not a CCM issue, but worth flagging since the in-cluster CCM commonly runs under Instance Principal.

[oracle-contributor-agreement]

Thank you for your pull request and welcome to our community! To contribute, please sign the Oracle Contributor Agreement (OCA).
The following contributors of this PR have not signed the OCA:

• PR author: p1kp
• karanbparmar45@gmail.com (@karanbparmar)

To sign the OCA, please create an Oracle account and sign the OCA in Oracle's Contributor Agreement Application.

When signing the OCA, please provide your GitHub username. After signing the OCA and getting an OCA approval from Oracle, this PR will be automatically updated.

If you are an Oracle employee, please make sure that you are a member of the main Oracle GitHub organization, and your membership in this organization is public.