What are the specific permissions required by KOTS in minimal RBAC installations?

Supporting your customers
1

By default, In minimal RBAC installations, KOTS will attempt to acquire * * * permissions on the target namespace. If the user running the install/upgrade command does not have * * * permissions on the target namespace, the installation will fail with a similar error message to the following:

failed to ensure kotsadm role: failed to create role: [roles.rbac.authorization.k8s.io](http://roles.rbac.authorization.k8s.io/) "kotsadm-role" is forbidden: user "<user>" (groups=["system:authenticated:oauth" "system:authenticated"]) is attempting to grant RBAC permissions not currently held

In some strict environments, granting * * * permissions is not an option, even if it’s limited to a single namespace. Are there custom RBAC roles with specific permissions that can be used or pre-created instead of granting the user * * * permissions on the target namespace?

2

Answer:

Here are the RBAC objects with the specific required permissions (usage instructions below):

apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    kots.io/backup: velero
    kots.io/kotsadm: "true"
  name: kotsadm
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  labels:
    kots.io/backup: velero
    kots.io/kotsadm: "true"
  name: kotsadm-role
rules:
  - apiGroups: [""]
    resources: ["configmaps", "persistentvolumeclaims", "pods", "secrets", "services", "limitranges"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
  - apiGroups: ["apps"]
    resources: ["daemonsets", "deployments", "statefulsets"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
  - apiGroups: ["batch"]
    resources: ["jobs", "cronjobs"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
  - apiGroups: ["networking.k8s.io", "extensions"]
    resources: ["ingresses"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
  - apiGroups: [""]
    resources: ["namespaces", "endpoints", "serviceaccounts"]
    verbs: ["get"]
  - apiGroups: ["authorization.k8s.io"]
    resources: ["selfsubjectaccessreviews", "selfsubjectrulesreviews"]
    verbs: ["create"]
  - apiGroups: ["rbac.authorization.k8s.io"]
    resources: ["roles", "rolebindings"]
    verbs: ["get"]
  - apiGroups: [""]
    resources: ["pods/log", "pods/exec"]
    verbs: ["get", "list", "watch", "create"]
  - apiGroups: ["batch"]
    resources: ["jobs/status"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  labels:
    kots.io/backup: velero
    kots.io/kotsadm: "true"
  name: kotsadm-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: kotsadm-role
subjects:
- kind: ServiceAccount
  name: kotsadm

Now, you’ll need to create those manually by saving that content in a file (say rbac.yaml) and then running:

kubectl apply -f rbac.yaml -n <namespace>

After that, you’ll need to pass the --ensure-rbac=false and --skip-rbac-check flags to the install command so that KOTS doesn’t try to re-create them, like so:

kubectl kots install <app-slug> -n <namespace> --ensure-rbac=false --skip-rbac-check ...

You will also need to pass those flags to the upgrade command when upgrading KOTS later, like so:

kubectl kots admin-console upgrade -n <namespace> --ensure-rbac=false --skip-rbac-check ...

Hope that helps.

1 Like