mirror of https://github.com/k3s-io/k3s
Add ADR
Signed-off-by: Brad Davidson <brad.davidson@rancher.com>
(cherry picked from commit 612473755d
)
pull/7763/head
parent
29bc03305a
commit
3e22bec190
|
@ -0,0 +1,25 @@
|
||||||
|
# Use a dedicated user for K3s core controllers
|
||||||
|
|
||||||
|
Date: 2023-05-26
|
||||||
|
|
||||||
|
## Status
|
||||||
|
|
||||||
|
Accepted
|
||||||
|
|
||||||
|
## Context
|
||||||
|
|
||||||
|
Users who collect audit logs from K3s currently have a hard time determining if an action was performed by an administrator, or by the K3s supervisor.
|
||||||
|
This is due to the K3s supervisor using the same `system:admin` user for both the admin kubeconfig, and the kubeconfig used by core Wrangler controllers that drive core functionality and the deploy/helm controllers.
|
||||||
|
|
||||||
|
Users may have policies in place that prohibit use of the `system:admin` account, or that require service accounts to be distinct from user accounts.
|
||||||
|
|
||||||
|
## Decision
|
||||||
|
|
||||||
|
* We will add a new kubeconfig for the K3s supervisor controllers: core functionality, deploy (AddOns; aka the manifests directory), and helm (HelmChart/HelmChartConfig).
|
||||||
|
* Each of the three controllers will use a dedicated user-agent to further assist in discriminating between events, via both audit logs and resource ManageFields tracking.
|
||||||
|
* The new user account will use exisiting core Kubernetes group RBAC.
|
||||||
|
|
||||||
|
## Consequences
|
||||||
|
|
||||||
|
* K3s servers will create and manage an additional kubeconfig, client cert, and key that is intended only for use by the supervisor controllers.
|
||||||
|
* K3s supervisor controllers will use distinct user-agents to further discriminate between which component initiated the request.
|
Loading…
Reference in New Issue