[zheng1771]

Description

Check access to the UserData selected by cniconfigurationid before
creating a Kubernetes cluster.

Add @acl to the API parameter, matching other UserData parameters.
Also validate the reference in the cluster service: reject a missing
record and check caller access before cluster creation proceeds.

An omitted CNI configuration is still allowed. Existing cluster
references are not changed.

Types of changes

• Breaking change (fix or feature that would cause existing functionality to change)
• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Enhancement (improves an existing feature and functionality)
• Cleanup (Code refactoring and cleanup, that may add test cases)
• Build/CI
• Test (unit or integration test code)

Feature/Enhancement Scale or Bug Severity

Feature/Enhancement Scale

• Major
• Minor

Bug Severity

• BLOCKER
• Critical
• Major
• Minor
• Trivial

The selected UserData must be accessible to the caller.

Screenshots (if appropriate):

Not applicable. Backend change.

How Has This Been Tested?

All 33 KubernetesClusterManagerImplTest tests and 13 ParamProcessWorkerTest
tests passed. Required modules compiled and Checkstyle passed.

How did you try to break this feature and the system with this change?

Added regression tests for:

• An omitted CNI configuration.
• An accessible UserData reference.
• An inaccessible UserData reference passed to cluster creation.
• A missing UserData reference passed to cluster creation.

Rejected requests stop before cluster persistence or further cluster
parameter processing. Existing API parameter access-check tests also passed.