Malformed Info log String in authmanager.go

[scranshoff]

Is this a BUG REPORT or FEATURE REQUEST?:

/kind bug

What happened:

Malformed Info log string in authmanager.go occurs because of bad string concatenation.

Example output:

{"level":"info","time":"2024-11-14T17:22:56.632405175Z","caller":"common/authmanager.go:472","msg":"auth manager: user vcenter.example.local on vCenter [{{} "ClusterComputeResource:domain-c8" [{{} "Host.Config.Storage" %!q(bool=false)}]}] doesn't have privileges for any ClusterComputeResource. HasUserPrivilegeOnEntities returns [Host.Config.Storage], when checking privileges [ClusterComputeResource:domain-c13] on entities %!v(MISSING)[email protected]","TraceId":"50a0d607-5fd0-460c-a2fc-0729cbdfa6aa"}

What you expected to happen:

Variables to be correctly placed in the Info log string

Example output:

{"level":"info","time":"2024-11-14T17:22:56.632405175Z","caller":"common/authmanager.go:472","msg":"auth manager: user [email protected] on vCenter vcenter.example.local doesn't have privileges for any ClusterComputeResource. HasUserPrivilegeOnEntities returns [{{} "ClusterComputeResource:domain-c13" [{{} "Host.Config.Storage" %!q(bool=false)}]}] , when checking privileges [Host.Config.Storage] on entities [ClusterComputeResource:domain-c13].","TraceId":"50a0d607-5fd0-460c-a2fc-0729cbdfa6aa"}

How to reproduce it (as minimally and precisely as possible):

To reproduce:

• Do not assign "Host.Config.Storage" Permissions to the user specified in the vsphere-csi-config-secret secret
• Attempt to create a PVC with RWX capabilities
• Check the logs of the controller for the above info log

Anything else we need to know?:

Environment:

• csi-vsphere version: 3.3.0
• vsphere-cloud-controller-manager version: ANY
• Kubernetes version: ANY
• vSphere version: ANY

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale