From b8ed9f10bf74016da06816ff604eb34804e8a3b0 Mon Sep 17 00:00:00 2001
From: Shubham Pampattiwar <spampatt@redhat.com>
Date: Mon, 9 Dec 2024 12:31:57 -0800
Subject: [PATCH] Fix OADP-5184: Add doc for automount_service_account_token
 exception (#1596)

* add doc for automount_service_account_token exception

* address PR feedback
---
 ...tomount_service_account_token_exception.md | 51 +++++++++++++++++++
 1 file changed, 51 insertions(+)
 create mode 100644 docs/automount_service_account_token_exception.md

diff --git a/docs/automount_service_account_token_exception.md b/docs/automount_service_account_token_exception.md
new file mode 100644
index 0000000000..b2ecb38cb6
--- /dev/null
+++ b/docs/automount_service_account_token_exception.md
@@ -0,0 +1,51 @@
+# **Knowledge Base Article: Why the OADP Operator Pod Requires `automountServiceAccountToken` to Be Enabled**
+
+---
+
+## **Rationale for Allowing the Default `automountServiceAccountToken` Behavior in OADP Operator Pods**
+
+The Kubernetes Best Practices team recommends setting `automountServiceAccountToken: false` for pods to reduce security risks by minimizing exposure of service account tokens. However, the **OADP Operator Pod** (`openshift-adp-controller-manager`) relies on the Kubernetes API server for its critical functions, and disabling the token mount would render it inoperable. While the OADP Operator Pod does not explicitly set `automountServiceAccountToken: true`, it depends on the **default Kubernetes behavior**, which mounts the service account token into the pod.
+
+---
+
+## **Why OADP Operator Requires Kubernetes API Access**
+
+The OADP Operator is a Kubernetes operator designed to manage backup and restore workflows. To perform these functions, it must interact extensively with the Kubernetes API server. This access is essential for the following reasons:
+
+### **1. Managing Custom Resources**
+- The OADP Operator interacts with CRDs such as:
+    - `BackupStorageLocation`
+    - `VolumeSnapshotLocation`
+    - `DataProtectionApplication`
+    - and many more
+
+### **2. Orchestrating Velero Components**
+- The operator configures and manages Velero resources to:
+    - Trigger and manage backups.
+    - Restore workloads to the cluster.
+    - Interact with PersistentVolumes, cloud storage, and VolumeSnapshot resources.
+
+### **3. Implementing the Controller Pattern**
+- The operator continuously watches for changes in the cluster via the Kubernetes API server and reconciles resources as needed.
+- This requires persistent and authenticated communication with the API server.
+
+---
+
+## **Why the Default Behavior Is Essential**
+
+By default, Kubernetes mounts the service account token into pods unless explicitly disabled (`automountServiceAccountToken: false`). This default behavior is critical for the OADP Operator due to the following reasons:
+
+### **1. Authentication for API Server Access**
+- The service account token provides the necessary authentication for the operator pod to access the Kubernetes API server.
+- Without this token, the operator cannot perform any of its intended functions, such as managing resources or reconciling the desired state.
+
+### **2. Alignment with Kubernetes Operator Design**
+- The OADP Operator relies on the standard Kubernetes operator design, which assumes that service account tokens are automatically mounted into pods.
+- Rewriting the operator to use alternative authentication methods (e.g., manually injected secrets) would introduce significant complexity and deviate from best practices for operator development.
+
+### **3. Maintaining Backup and Restore Functionality**
+- The OADP Operator facilitates critical backup and restore operations for workloads in the cluster.
+- Disabling `automountServiceAccountToken` would result in failed operations.
+- Short Term Service Account tokens are rotated externally via cloud-credentials-operator requires us to use the automount token to authenticate against cloud providers.
+
+---