Limit Default RBAC Rules For Kanister Operator (#3134)

Signed-off-by: Rajat Gupta <rajat.gupta@veeam.com>
Co-authored-by: Vivek Singh <vsingh.ggits.2010@gmail.com>

docs/index.rst

@@ -21,6 +21,7 @@ and easy to install, operate and scale.
 
    overview
    install
+   rbac
    tutorial
    architecture
    tasks

docs/install.rst

@@ -43,6 +43,13 @@ You should see the operator pod in the ``Running`` state:
   best-effort basis. If you are using an older version of Kubernetes, please
   consider upgrading to a newer version.
 
+.. note::
+  To improve the cluster's security, the default installation of Kanister is restricted
+  to access only the resources within its own namespace. As a result, Kanister may not be
+  able to snapshot or restore applications by default in other namespaces.
+  If Blueprint needs access to resources in other namespaces, please follow the steps
+  provided here :ref:`rbac` to configure the access correctly.
+
 Configuring Kanister
 ====================
 

docs/rbac.rst

@@ -0,0 +1,69 @@
+.. _rbac:
+
+RBAC Configuration
+******************
+
+The `edit` `ClusterRole` is a built-in Kubernetes system role that offers
+permissions to modify most objects within a namespace, excluding roles,
+role bindings, and resource quotas. This role allows access to create, update,
+delete, and view resources such as Deployments, Pods, Services, ConfigMaps,
+PersistentVolumeClaims, and more. The Kanister Helm chart used to assign the
+`edit` `ClusterRole` to the Kanister service account, which granted all the
+permissions mentioned in the `edit` `ClusterRole` to the Kanister application.
+
+To enhance security, the `edit` `ClusterRoleBinding` has been removed from
+the Kanister Helm Chart. Users are required to create their own
+`Role`/`RoleBinding` in the application's namespace to grant the necessary
+permissions to Kanister's Service Account, providing more control over
+the specific permissions granted.
+
+Creating a RoleBinding with edit ClusterRole
+============================================
+
+To allow Kanister to perform backup/restore operations in the application
+namespace, create a `RoleBinding` in the application namespace that assigns
+the `edit` `ClusterRole` to Kanister's Service Account:
+
+.. code-block:: bash
+
+  kubectl create rolebinding kanister-edit-binding --clusterrole=edit \
+  --serviceaccount=<release-namespace>:<release-name>-kanister-operator \
+  --namespace=<application-namespace>
+
+Creating a Role with Granular Permissions
+=========================================
+
+If Blueprint doesn't require access to all the resources that are included
+in the `edit` ClusterRole, you can create a `Role` in application namespace
+with just the specific resources and verbs that Blueprint needs, and a `RoleBinding`
+in application namespace to bind the `Role` to Kanister's Service Account.
+This approach enhances security by granting only the necessary permissions.
+
+1. Create a `Role` with the permissions required by the Blueprint:
+
+.. code-block:: yaml
+
+  apiVersion: rbac.authorization.k8s.io/v1
+  kind: Role
+  metadata:
+    name: kanister-role
+    namespace: <application-namespace>
+  rules:
+  - apiGroups: [""]
+    resources: ["pods", "pods/log", "persistentvolumeclaims" ,"secrets"]
+    verbs: ["get", "list", "watch"]
+  - apiGroups: ["apps"]
+    resources: ["deployments", "statefulsets"]
+    verbs: ["get", "list", "watch"]
+
+2. Create a `RoleBinding` to bind the `Role` to Kanister's Service Account:
+
+.. code-block:: bash
+
+  kubectl create rolebinding kanister-role-binding --role=kanister-role \
+  --serviceaccount=<release-namespace>:<release-name>-kanister-operator \
+  --namespace=<application-namespace>
+
+After setting up the required `Role`/`RoleBinding`, Kanister will be able
+to successfully perform snapshot and restore operations in the application's
+namespace.

docs/tutorial.rst

@@ -25,6 +25,8 @@ Prerequisites
 
 * A running Kanister controller. See :ref:`install`
 
+* Proper RBAC configured for the Kanister controller. See :ref:`rbac`
+
 * Access to an S3 bucket and credentials.
 
 Example Application

docs_new/.vitepress/config.mts

@@ -23,6 +23,7 @@ export default defineConfig({
     sidebar: [
       { text: "Overview", link: "/overview" },
       { text: "Installation", link: "/install" },
+      { text: "RBAC Configuration", link: "/rbac" },
       { text: "Tutorial", link: "/tutorial" },
       { text: "Architecture", link: "/architecture" },
       { text: "Tooling", link: "/tooling" },

docs_new/install.md

@@ -40,6 +40,15 @@ is provided on a best-effort basis. If you are using an older version of
 Kubernetes, please consider upgrading to a newer version.
 :::
 
+::: tip NOTE
+
+To improve the cluster's security, the default installation of Kanister is restricted
+to access only the resources within its own namespace. As a result, Kanister may not be
+able to snapshot or restore applications by default in other namespaces.
+If Blueprint needs access to resources in other namespaces, please follow the steps
+provided [here](rbac) to configure the access correctly.
+:::
+
 ## Configuring Kanister
 
 Use the `helm show values` command to list the configurable options:

docs_new/rbac.md

@@ -0,0 +1,65 @@
+# RBAC Configuration {#rbac}
+
+The `edit` `ClusterRole` is a built-in Kubernetes system role that offers
+permissions to modify most objects within a namespace, excluding roles,
+role bindings, and resource quotas. This role allows access to create, update,
+delete, and view resources such as Deployments, Pods, Services, ConfigMaps,
+PersistentVolumeClaims, and more. The Kanister Helm chart used to assign the
+`edit` `ClusterRole` to the Kanister service account, which granted all the
+permissions mentioned in the `edit` `ClusterRole` to the Kanister application.
+
+To enhance security, the `edit` `ClusterRoleBinding` has been removed from 
+the Kanister Helm Chart. Users are required to create their own 
+`Role`/`RoleBinding` in the application's namespace to grant the necessary 
+permissions to Kanister's Service Account, providing more control over 
+the specific permissions granted.
+
+
+## Creating a RoleBinding with edit ClusterRole
+
+To allow Kanister to perform backup/restore operations in the application
+namespace, create a `RoleBinding` in the application namespace that assigns
+the `edit` `ClusterRole` to Kanister's Service Account:
+
+```bash
+kubectl create rolebinding kanister-edit-binding --clusterrole=edit \
+--serviceaccount=<release-namespace>:<release-name>-kanister-operator \
+--namespace=<application-namespace>
+```
+
+## Creating a Role with Granular Permissions
+
+If the Blueprint doesn't require access to all the resources that are included
+in the `edit` ClusterRole, you can create a `Role` in the application namespace
+with just the specific resources and verbs that Blueprint needs, and a `RoleBinding`
+in the application namespace to bind the `Role` to Kanister's Service Account.
+This approach enhances security by granting only the necessary permissions.
+
+1. Create a `Role` with the permissions required by the Blueprint:
+
+   ```yaml
+   apiVersion: rbac.authorization.k8s.io/v1
+   kind: Role
+   metadata:
+     name: kanister-role
+     namespace: <application-namespace>
+   rules:
+   - apiGroups: [""]
+     resources: ["pods", "pods/log", "persistentvolumeclaims", "secrets"]
+     verbs: ["get", "list", "watch"]
+   - apiGroups: ["apps"]
+     resources: ["deployments", "statefulsets"]
+     verbs: ["get", "list", "watch"]
+   ```
+
+2. Create a `RoleBinding` to bind the `Role` to Kanister's Service Account:
+
+   ```bash
+   kubectl create rolebinding kanister-role-binding --role=kanister-role \
+   --serviceaccount=<release-namespace>:<release-name>-kanister-operator \
+   --namespace=<application-namespace>
+   ```
+
+After setting up the required `Role`/`RoleBinding`, Kanister will be able
+to successfully perform snapshot and restore operations in the application's
+namespace.

docs_new/tutorial.md

@@ -14,6 +14,7 @@ use more of Kanister's features to manage the application's data.
     `helm init`
 - docker
 - A running Kanister controller. See [install](install)
+- Proper RBAC configured for the Kanister controller. See [RBAC Configuration](rbac)
 - Access to an S3 bucket and credentials.
 
 ## Example Application

helm/kanister-operator/templates/rbac.yaml

@@ -39,21 +39,6 @@ rules:
 ---
 kind: ClusterRoleBinding
 apiVersion: rbac.authorization.k8s.io/v1
-metadata:
-  labels:
-{{ include "kanister-operator.helmLabels" . | indent 4 }}
-  name: {{ template "kanister-operator.fullname" . }}-edit-role
-roleRef:
-  apiGroup: rbac.authorization.k8s.io
-  kind: ClusterRole
-  name: edit
-subjects:
-- kind: ServiceAccount
-  name: {{ template "kanister-operator.serviceAccountName" . }}
-  namespace: {{ .Release.Namespace }}
----
-kind: ClusterRoleBinding
-apiVersion: rbac.authorization.k8s.io/v1
 metadata:
   labels:
 {{ include "kanister-operator.helmLabels" . | indent 4 }}

releasenotes/notes/limit-rbac-kanister-operator-3c933af021b8d48a.yaml

@@ -0,0 +1,5 @@
+---
+upgrade:
+  - Users upgrading from previous versions should note that the `edit` `ClusterRoleBinding` is no longer included by default. They must now create their own `Role` / `RoleBinding` with appropriate permissions for Kanister's Service Account in the application's namespace.
+security:
+  - Enhanced security by removing the default `edit` `ClusterRoleBinding` assignment, minimizing the risk of excessive permissions.