fix: use a LocalObjectReference for credentials Secret

[dkoshkin]

Using a cross-namespace objectRef in the cluster API can lead to privilege escalation.
A user with RBAC to read Secrets in one namespace can create a cluster, and copy any Secret from any other namespace to their workload cluster.

[faiq]

Does this makes it so a user can only deploy one cluster only in the same namespace as CAREN?

[dkoshkin]

Does this makes it so a user can only deploy one cluster only in the same namespace as CAREN?

Good question. No, a user can deploy a Cluster in any namespace where they have RBAC permissions to create the Cluster and Secret objects, but using a local ref guarantees that a user can only copy Secrets in that same namespace.

The CAREN controller has elevated privileges, so it can still create clusters in any namespace, from 1 or multiple users.

[faiq]

Good question. No, a user can deploy a Cluster in any namespace where they have RBAC permissions to create the Cluster and Secret objects, but using a local ref guarantees that a user can only copy Secrets in that same namespace.

Wouldn't the same namespace be the same namespace as the running process?

[dkoshkin]

Good question. No, a user can deploy a Cluster in any namespace where they have RBAC permissions to create the Cluster and Secret objects, but using a local ref guarantees that a user can only copy Secrets in that same namespace.

Wouldn't the same namespace be the same namespace as the running process?

I may misunderstanding, but by the "same namespace" I meant same namespace as the Cluster.
Notice the Secret that CAREN is trying to read it from is using the Cluster Namespace: req.Cluster.Namespace,
https://github.com/d2iq-labs/cluster-api-runtime-extensions-nutanix/pull/37/files#diff-174d511aea21d4b975137ea0502067a5cb1b145fe839dbe8fa12d1fc618e1b76R91

[supershal]

LGTM. Lets start creating unit tests for add-on handlers. I will create issue if its not already there.