Restricting Wildcard RBAC Permissions for the Akuity Upgrader

Security scans (Kyverno / RBAC policy enforcement) may flag the Akuity upgrader Role for using wildcard (*) permissions across API groups, resources, and verbs. These findings typically appear as high-severity violations because wildcard permissions can grant broader access than necessary.

A Kyverno policy report flags the following violation for the akuity-upgrader Role:

"Wildcards should not be used in a rules apiGroups, resources, or verbs"
Noncompliant rules:
{"apiGroups":["*"],"resources":["*"],"verbs":["*"]}

Why the Akuity Upgrader Uses Wildcards

The Akuity upgrader is responsible for:

• Patching Akuity-managed resources

• Updating deployments, jobs, and configuration objects

• Handling version upgrades that may introduce new resource types

Because upgrades can affect multiple Kubernetes resource kinds, wildcard permissions are used by default to:

• Avoid upgrade failures

• Ensure forward compatibility

• Reduce operational friction during version changes

Why the Akuity Upgrader Uses Wildcards

The Akuity upgrader is responsible for:

• Patching Akuity-managed resources

• Updating deployments, jobs, and configuration objects

• Handling version upgrades that may introduce new resource types

Because upgrades can affect multiple Kubernetes resource kinds, wildcard permissions are used by default to:

• Avoid upgrade failures

• Ensure forward compatibility

• Reduce operational friction during version changes

Example: Restricted Role Configuration (Starting Point)

Minimum Required Verbs

At a minimum, the upgrader requires the following verbs:

• get

• patch

• delete

Depending on your environment and upgrade workflows, the following may also be required:

• list

• watch

• update

• create

⚠️ Important: There is no officially published minimal RBAC matrix for the upgrader. Any restriction must be tested.

Below is an example of reducing wildcard verbs while retaining functional access:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: akuity-upgrader
  namespace: akuity
rules:
- apiGroups: ["apps", "batch", ""]
  resources:
    - deployments
    - jobs
    - pods
    - configmaps
    - secrets
  verbs:
    - get
    - list
    - watch
    - patch
    - update
    - delete

This example is illustrative only. Additional API groups or resources may be required depending on your Akuity version and enabled features.

Because restricted permissions may cause upgrade failures, follow this validation process:

1. Apply RBAC changes in a non-production environment

2. Trigger the Akuity upgrader

   • Example: apply a version change or configuration update

3. Monitor the upgrader Job/Pod

    

   kubectl logs -n akuity job/akuity-upgrader


4. Look for RBAC errors

   • forbidden

   • cannot patch resource

   • cannot delete resource

5. Iteratively expand permissions only as needed

Restricting wildcard RBAC permissions for the Akuity upgrader is feasible but requires careful testing and incremental hardening. Start with minimal verbs (get, patch, delete), validate upgrade workflows, and expand permissions only when required. This approach balances security compliance with operational reliability.