[Part 26] Reading Kubernetes Configuration While Blocking Changes — QueryPie Roles and Policies

Checking Kubernetes settings does not necessarily require changing them. Incident investigation or deployment checks often need only current values.

I gave a developer ConfigMap read access in QueryPie Community and blocked modifications. Browser reads worked, Apply was denied by policy, and both attempts were auditable.

Registering a Lab Kubernetes Cluster

I registered a separate Mac cluster as acp-kac-lab and created ConfigMap kac-fixture in namespace orders-lab, simulating order-service settings. ConfigMaps store application configuration values.

I entered API address and credentials, clicked Verify Credential, confirmed Verified, and saved with Request Audit enabled.

Creating a Role for Configuration Inspection

Orders Lab ConfigMap Read Only permits get/list/watch on ConfigMaps in orders-lab and denies patch/update on kac-fixture. Cluster, resource type, and operations can be specified separately.

I attached it to Orders Lab Viewer and assigned Demo Developer. Role assignment also exposes an expiration date. Bundling task privileges in one role was convenient.

Opening Configuration as the Developer

Demo Developer selected Orders Lab Viewer in Kubernetes and clicked Connect, opening Web Client in the browser.

In Config & Storage → ConfigMap, orders-lab listed kac-fixture. Its YAML showed status READY.

The user could read necessary settings without cluster-wide administration. Operators define boundaries; users choose a role and inspect permitted information.

Attempting to Change the Same Setting

Edit changed status from READY to QUERYPIE_CHANGE_TEST. View Diff compared the single line before and after, clarifying the intended change before Apply.

Apply returned ‘QueryPie - Denied by policy to access the resource.’ Reads were allowed, but the modification was denied by QueryPie policy.

After closing and refreshing, status was still READY and resource version unchanged. Reads continued, but the unauthorized change never applied.

The underlying Kubernetes permissions allowed this change in the lab. QueryPie’s read-only policy added the denial, demonstrating task-specific control on top of Kubernetes privileges.

Auditing Who Attempted Which Change

Audit → Kubernetes → Request Audit contained the reads and modification. Details identified Demo Developer, Orders Lab Viewer, acp-kac-lab, and orders-lab/kac-fixture.

Verb was update and Event Type DENY. The message explained policy denial, and Request Body retained QUERYPIE_CHANGE_TEST.

The administrator could inspect the attempted work, not just the fact of a block, before asking the user for an explanation.

Separating Reads from Changes in Operations

The read after the failed change was get, Success, Event Type ALLOW, Request Source Web Client. The Kubernetes group qp-kac-demo was also visible.

‘Inspect settings without delegating changes’ can be expressed as policy and role. Users read in the browser; administrators control modifications and inspect requests.

This extended the same management pattern from databases and servers to Kubernetes. A unified view of users, privileges, and activity across resources should help evaluators.

This lab used QueryPie Community 11.6.7 Web Client (Beta), a separate cluster, and a ConfigMap containing only test values.

References: Kubernetes policy syntax · Web Client user guide · Request Audit