IAM-backed ObjectStores generate wildcard Secret RBAC

Start at the Role generation and AWS credential-reference collection paths, then compare them with the existing Azure default/managed identity handling. Verify the IAM-inheritance case and the explicit credential Secret case, and add or update tests so completion means no Secret rule for an empty collection and a scoped rule when Secret names are present.

Summary

When an ObjectStore uses AWS IAM role inheritance (inheritFromIAMRole: true) and does not reference any credential Secrets, the generated <cluster>-barman-cloud Role still contains a secrets rule with no resourceNames.

In Kubernetes RBAC, an omitted or empty resourceNames list does not restrict the rule to no objects; it allows the verbs on all resources of that type. As a result, an IAM-backed barman-cloud instance can get/list/watch every Secret in the namespace even though barman-cloud does not need any Secret for the AWS credential chain.

Why this matters

Deployments using IRSA, pod identity, or IMDS typically set inheritFromIAMRole: true so barman-cloud gets credentials from the pod environment. In that mode, barman-cloud returns before reading AWS credential Secret references, so the plugin should not grant Secret access unless a credential Secret is actually needed.

Expected behavior

If no credential Secret names are collected for the ObjectStores referenced by a cluster, the generated Role should not include a secrets rule. For AWS credentials with inheritFromIAMRole: true, AWS Secret references should be ignored the same way Azure default/managed identity credentials are ignored today.

Actual behavior

The Role includes a secrets rule with an empty resourceNames field, which grants access to all Secrets in the namespace.

Proposed fix

• Skip AWS credential Secret references when inheritFromIAMRole is true.
• Omit the generated secrets PolicyRule when the collected Secret name set is empty.
• Keep the existing scoped secrets rule when explicit credential Secret refs are present.