OCPBUGS-74496: Add UserAgent to Azure SDK client telemetry options

[Nirshal]

What this PR does / why we need it

The Cloud Network Config Controller (CNCC) is not setting the ApplicationID in the Azure SDK TelemetryOptions when creating Azure ARM SDK clients and credential clients. This means Azure
API requests from CNCC do not include proper application identification in the User-Agent header for request tracing and telemetry purposes.

Note: the UserAgent constant is already defined in the codebase (cloud-network-config-controller) but was only applied to GCP clients, not Azure clients.

This PR adds policy.TelemetryOptions with ApplicationID to:

• ARM clients (VirtualMachinesClient, InterfacesClient, VirtualNetworksClient)
• Azure credential clients (UserAssignedIdentityCredential, WorkloadIdentityCredential, ClientSecretCredential)

Which issue(s) this PR fixes

Fixes https://issues.redhat.com/browse/OCPBUGS-74496

Special notes for your reviewer

• The UserAgent constant value is cloud-network-config-controller (31 characters), but the Azure SDK enforces a maximum of 24 characters with no spaces for ApplicationID and silently truncates it to cloud-network-config-con. This has been flagged in the Jira issue for discussion.

Checklist

• Subject and description added to both the commit and PR
• Relevant issues referenced
• Unit tests included

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[openshift-ci-robot]

@Nirshal: This pull request references Jira Issue OCPBUGS-74496, which is valid. The bug has been moved to the POST state.

3 validation(s) were run on this bug

• bug is open, matching expected state (open)
• bug target version (4.22.0) matches configured target version for branch (4.22.0)
• bug is in the state New, which is one of the valid states (NEW, ASSIGNED, POST)

Requesting review from QA contact:
/cc @wewang58

The bug has been updated to refer to the pull request using the external bug tracker.

Details

In response to this:

What this PR does / why we need

it

The Cloud Network Config Controller (CNCC) is not setting the ApplicationID in the Azure SDK TelemetryOptions when creating Azure ARM SDK clients and credential clients. This means Azure
API requests from CNCC do not include proper application identification in the User-Agent header for request tracing and telemetry purposes.

Note: the UserAgent constant is already defined in the codebase (cloud-network-config-controller) but was only applied to GCP clients, not Azure clients.

This PR adds policy.TelemetryOptions with ApplicationID to:

• ARM clients (VirtualMachinesClient, InterfacesClient, VirtualNetworksClient)
• Azure credential clients (UserAssignedIdentityCredential, WorkloadIdentityCredential, ClientSecretCredential)

Which issue(s) this PR fixes

Fixes https://issues.redhat.com/browse/OCPBUGS-74496

Special notes for your reviewer

• The UserAgent constant value is cloud-network-config-controller (36 characters), but the Azure SDK enforces a maximum of 24 characters with no spaces for ApplicationID and
  silently truncates it to cloud-network-config-con. This has been flagged in the Jira issue for discussion.

Checklist

• Subject and description added to both the commit and PR
• Relevant issues referenced
• Unit tests included

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@Nirshal: This pull request references Jira Issue OCPBUGS-74496, which is valid.

3 validation(s) were run on this bug

• bug is open, matching expected state (open)
• bug target version (4.22.0) matches configured target version for branch (4.22.0)
• bug is in the state POST, which is one of the valid states (NEW, ASSIGNED, POST)

Requesting review from QA contact:
/cc @wewang58

Details

In response to this:

What this PR does / why we need it

The Cloud Network Config Controller (CNCC) is not setting the ApplicationID in the Azure SDK TelemetryOptions when creating Azure ARM SDK clients and credential clients. This means Azure
API requests from CNCC do not include proper application identification in the User-Agent header for request tracing and telemetry purposes.

Note: the UserAgent constant is already defined in the codebase (cloud-network-config-controller) but was only applied to GCP clients, not Azure clients.

This PR adds policy.TelemetryOptions with ApplicationID to:

• ARM clients (VirtualMachinesClient, InterfacesClient, VirtualNetworksClient)
• Azure credential clients (UserAssignedIdentityCredential, WorkloadIdentityCredential, ClientSecretCredential)

Which issue(s) this PR fixes

Fixes https://issues.redhat.com/browse/OCPBUGS-74496

Special notes for your reviewer

• The UserAgent constant value is cloud-network-config-controller (36 characters), but the Azure SDK enforces a maximum of 24 characters with no spaces for ApplicationID and silently truncates it to cloud-network-config-con. This has been flagged in the Jira issue for discussion.

Checklist

• Subject and description added to both the commit and PR
• Relevant issues referenced
• Unit tests included

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[coderabbitai]

Important

Review skipped

Auto reviews are limited based on label configuration.

🚫 Review skipped — only excluded labels are configured. (1)

• do-not-merge/work-in-progress

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 915c26e3-bf4c-41b0-96b7-8e6d80412422

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[kyrtapz]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: kyrtapz, Nirshal

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [kyrtapz]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[Nirshal]

/retest

[openshift-ci]

@Nirshal: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/security	a953efc	link	false	/test security

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[Nirshal]

According to Claude e2e-analyze skill:

"Here is the analysis:

Error: Snyk security scan failed with 12 open issues (1 HIGH, 9 MEDIUM, 2 LOW) in vendored dependencies.

Summary: The CI job pull-ci-openshift-cloud-network-config-controller-main-security failed because the Snyk static code analysis scan found 12 security issues in the project's vendored
dependencies. The scan exits non-zero when open issues are found, causing the security-openshift-ci-security-snyk-scan step to fail after 1m39s. Notably, ALL findings are in vendor/
code — none are in the project's own source code.

Evidence:
- 1 HIGH: Generation of Error Message Containing Sensitive Information
→ vendor/sigs.k8s.io/controller-runtime/pkg/log/log.go:64 (fmt.Fprintf leaking error stack traces)
- 9 MEDIUM issues in vendored libraries:
→ 2x Hardcoded Passwords in vendor/github.com/aws/aws-sdk-go/aws/endpoints/dep_service_ids.go (lines 99, 100)
→ 2x Insecure TLS Configuration in vendor/github.com/google/s2a-go/internal/v2/tlsconfigstore/tlsconfigstore.go (lines 118, 119)
→ 3x Path Traversal in vendor/github.com/fsnotify/fsnotify/backend_kqueue.go (lines 419, 571, 584)
→ 1x Path Traversal in vendor/github.com/prometheus/procfs/net_dev_snmp6.go (line 62)
→ 1x Improper Certificate Validation in vendor/github.com/google/s2a-go (line 115)
- 2 LOW: Use of weak hash algorithms (MD5/SHA1) in vendor/github.com/gofrs/uuid/v5/generator.go (lines 267, 288)
- Exit code 1 from snyk, causing pod security-openshift-ci-security-snyk-scan to fail with ContainerFailed

Additional evidence:
- Full Snyk report: https://app.snyk.io/org/openshift-ci-internal/project/586616c8-4262-4bea-8dda-0100642a00fd/history/8c858217-bb7f-4f78-a09f-eb1d6d845817
- PR #208 by @Nirshal merging commit a953efc into openshift/cloud-network-config-controller@main (resolved to 6f38237)
- All 12 findings are in vendored third-party code, not in the project's own source. This is likely a pre-existing condition or caused by a dependency update in the PR. The fix would
involve either updating the affected dependencies to patched versions, or configuring Snyk ignores for vendor-directory false positives that are not actually exploitable in context."

[Nirshal]

/cc @wewang58