---
title: Restricting Wildcard RBAC Permissions for the Akuity Upgrader
description: Restricting Wildcard RBAC Permissions
---

[Skip to content](https://support.akuity.io/kb/restricting-wildcard-rbac-permissions-for-the-akuity-upgrader#main-content)

English

Show submenu for translations

[![Akuity-Logo-Color-1](https://support.akuity.io/hubfs/Akuity-Logo-Color-1.svg)](https://akuity.io/)

Open main navigation

Close main navigation

- English
  
  Show submenu for translations

 Hello. How can we help you?

- There are no suggestions because the search field is empty.

1. [Help Center](https://support.akuity.io/kb?hsLang=en)
2. [Akuity Platform](https://support.akuity.io/kb/akuity-platform?hsLang=en)
3. [Configuration](https://support.akuity.io/kb/akuity-platform?hsLang=en#configuration)

# Restricting Wildcard RBAC Permissions for the Akuity Upgrader

## How to reduce \* permissions on the akuity-upgrader Role without breaking upgrades

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**.

- [Argo CD](https://support.akuity.io/kb/argo-cd?hsLang=en#main-content)

    - [App of Apps](https://support.akuity.io/kb/argo-cd?hsLang=en#app-of-apps)
    - [Configuration](https://support.akuity.io/kb/argo-cd?hsLang=en#configuration)
    - [ApplicationSet](https://support.akuity.io/kb/argo-cd?hsLang=en#applicationset)
- [Akuity Platform](https://support.akuity.io/kb/akuity-platform?hsLang=en#main-content)

    - [Audit Logs](https://support.akuity.io/kb/akuity-platform?hsLang=en#audit-logs)
    - [IP Allow Lists](https://support.akuity.io/kb/akuity-platform?hsLang=en#ip-allow-lists)
    - [Terraform](https://support.akuity.io/kb/akuity-platform?hsLang=en#terraform)
    - [Configuration](https://support.akuity.io/kb/akuity-platform?hsLang=en#configuration)
    - [Agents](https://support.akuity.io/kb/akuity-platform?hsLang=en#agents)
    - [Troubleshooting](https://support.akuity.io/kb/akuity-platform?hsLang=en#troubleshooting)
- [Kargo](https://support.akuity.io/kb/kargo?hsLang=en#main-content)

    - [Configuration](https://support.akuity.io/kb/kargo?hsLang=en#configuration)
    - [Warehouses](https://support.akuity.io/kb/kargo?hsLang=en#warehouses)
    - [Metrics](https://support.akuity.io/kb/kargo?hsLang=en#metrics)
- [Self-hosted Akuity Platform](https://support.akuity.io/kb/self-hosted-akuity-platform?hsLang=en#main-content)

    - [Configuration](https://support.akuity.io/kb/self-hosted-akuity-platform?hsLang=en#configuration)

[![Akuity-Logo-Color-1](https://support.akuity.io/hubfs/Akuity-Logo-Color-1.svg "Akuity-Logo-Color-1")](https://akuity.io/)

Akuity.io Help Center

Copyright © 2025, Akuity Inc.