From 612473755d5be19b5041f19add196d006e27d36f Mon Sep 17 00:00:00 2001 From: Brad Davidson Date: Fri, 26 May 2023 23:50:17 +0000 Subject: [PATCH] Add ADR Signed-off-by: Brad Davidson --- docs/adrs/core-controller-user.md | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) create mode 100644 docs/adrs/core-controller-user.md diff --git a/docs/adrs/core-controller-user.md b/docs/adrs/core-controller-user.md new file mode 100644 index 0000000000..91a693c194 --- /dev/null +++ b/docs/adrs/core-controller-user.md @@ -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.