IAM-backed ObjectStores generate wildcard Secret RBAC

[martinohansen]

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.

[dosubot]

Hi @martinohansen! I'm Dosu and I’m helping the plugin-barman-cloud team.

I confirmed the issue you've described. The root cause is in CollectSecretNamesFromCredentials in internal/cnpgi/operator/specs/secrets.go [1] — the AWS credential branch unconditionally appends secret references without checking inheritFromIAMRole:

if barmanCredentials.AWS != nil {
    references = append(
        references,
        barmanCredentials.AWS.AccessKeyIDReference,
        barmanCredentials.AWS.SecretAccessKeyReference,
        barmanCredentials.AWS.RegionReference,
        barmanCredentials.AWS.SessionToken,
    )
}

In contrast, Azure already has the exact pattern you'd want here [2]:

if barmanCredentials.Azure != nil {
    if !barmanCredentials.Azure.UseDefaultAzureCredentials &&
        !barmanCredentials.Azure.InheritFromAzureAD {
        references = append(references, ...)
    }
}

Additionally, BuildRoleRules in internal/cnpgi/operator/rbac/role.go always emits the secrets PolicyRule regardless of whether the collected set is empty [3]. The stringset.ToSortedList() returns an empty non-nil slice []string{} [4], which in Kubernetes RBAC means "all secrets in the namespace" — exactly the wildcard behavior you've identified.

A fix would need two changes:

1. Skip AWS secret references when inheritFromIAMRole is true — guard the AWS branch similarly to Azure:

   if barmanCredentials.AWS != nil && !barmanCredentials.AWS.InheritFromIAMRole {
       references = append(references, ...)
   }

2. Omit the secrets PolicyRule when no secrets are needed — in BuildRoleRules, only append the secrets rule if secretsSet is non-empty:

   if secretsSet.Len() > 0 {
       rules = append(rules, rbacv1.PolicyRule{...})
   }

There are existing tests for the Azure skip logic [5] that could serve as a template for equivalent AWS inheritFromIAMRole tests.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.