percona · rasika-chivate · Oct 1, 2024 · Sep 16, 2024 · Sep 16, 2024 · Sep 16, 2024
diff --git a/docs/administer/manage_users.md b/docs/administer/manage_users.md
@@ -94,8 +94,10 @@ You will be prompted to enter the password for this user.
     ```
 
 !!! info "Important"
+
     For Percona Everest versions 1.0.0 and later, new users have full access to the system. However, once RBAC support is in place, an admin user will be able to manage permissions for users, granting them fine-grained control over database resources.
 
+For detailed information on granting permissions to new users, see [assign permissions to a new user](rbac.md#assign-users-to-a-group-and-grant-them-permissions) section.
 
 ### List the users
 

diff --git a/docs/administer/rbac.md b/docs/administer/rbac.md
diff --git a/docs/api_rbac.md b/docs/api_rbac.md
@@ -0,0 +1,48 @@
+# Navigating the breaking API changes for RBAC
+
+Starting with Percona Everest v1.2.0, breaking changes are being made to the API for `monitoring-instances` and `backup-storage` resources. These changes are:
+
+- Before the release of Percona Everest 1.2.0, these resources were globally scoped, but now they will be specific to namespaces. 
+
+- The database clusters can only use `monitoring-instances` and `backup-storages` located within the same namespace as the cluster. The system used a `.spec.allowedNamespaces` field to control access to these global resources. This field determined the namespaces where the resource could be accessed, providing a certain degree of access control.
+
+- With the update to Percona Everest v1.2.0, the shift from global scope to designated namespaces for these resources marks a significant change in the way access control is managed. This change enhances security by ensuring these resources are only accessible within their designated namespaces.
+
+## Challenges with globally scoped namespaces
+
+In Percona Everest v1.2.0, we’ve rolled out Role Based Access Control (RBAC) to enhance security and provide more granular control over the access privileges for specific resources within the system. This implementation provides fine-grained control over which users and user groups can access particular resources within the system. 
+
+The RBAC model functions on the principle that all resources are organized into namespaces. This enables a well-structured and hierarchical arrangement of resources, simplifying access rights management according to the namespace to which a resource is associated.
+
+Prior to Percona Everest version 1.2.0, certain resources such as `backup-storages` and `monitoring-instances` were not organized into namespaces but were accessible globally. To enforce access restrictions on these globally scoped resources, the system utilized a `.spec.allowedNamespaces` field. The `.spec.allowedNamespaces` field specifies the namespaces within which the resource can be accessed, giving you certain level of control.
+
+Using the `.spec.allowedNamespaces` field for globally scoped resources presented challenges when integrating with the core RBAC model. To fix this and align with the RBAC framework, `backup-storages` and `monitoring-instances` are now namespaced resources. This ensures that all resources conform to the same RBAC model, which results in a consistent and manageable access control structure across the system.
+
+##  Changes in the Percona Everest APIs
+
+The APIs have been updated with the following modifications:
+
+- The existing APIs for backup storage and monitoring instances are deprecated. Now, you should use the API path prefixed with `/namespaces/{namespace}`.
+
+    ??? example "Example"
+
+        ```/v1/backup-storages``` is now
+
+        ```/v1/namespaces/{namespace}/backup-storages```
+
+        Check out the [API](https://percona-everest.readme.io/reference/getkubernetesclusterresources) documentation for more details.
+
+- The `.spec.allowedNamespaces` field has been deprecated. Access control for these resources is now managed through the RBAC policy.
+
+- `database-clusters` can now only reference `backup-storages` and `monitoring-instances` created within the same namespace as the `database-cluster`.
+
+### Migrating to Percona Everest 1.2.0
+
+When upgrading to 1.2.0, all your existing backup-storages and monitoring-instances will be automatically migrated to the namespaces specified in their `.spec.allowedNamespaces `fields. After the upgrade, these resources will be accessible exclusively through the new API endpoints.
+
+Need more details? Check out the [upgrade](../upgrade_with_cli.md#upgrading-to-percona-everest-120) section.
+
+
+
+
+
diff --git a/docs/images/ CRD_upgrade_confirmation_1.png b/docs/images/ CRD_upgrade_confirmation_1.png
diff --git a/docs/images/CRD_upgrade_confirmation.png b/docs/images/CRD_upgrade_confirmation.png
diff --git a/docs/images/CRD_upgrade_confirmation_1.png b/docs/images/CRD_upgrade_confirmation_1.png
diff --git a/docs/images/database_details.png b/docs/images/database_details.png
diff --git a/docs/images/datbase_view_page.png b/docs/images/datbase_view_page.png
diff --git a/docs/images/dev_role_db_cluster_update.png b/docs/images/dev_role_db_cluster_update.png
diff --git a/docs/images/dev_role_monitor_read.png b/docs/images/dev_role_monitor_read.png
diff --git a/docs/images/dev_role_storage_read.png b/docs/images/dev_role_storage_read.png
diff --git a/docs/images/enable_sharding.png b/docs/images/enable_sharding.png
diff --git a/docs/images/everest_db_scaling.png b/docs/images/everest_db_scaling.png
diff --git a/docs/images/everest_resources_allocated.png b/docs/images/everest_resources_allocated.png
diff --git a/docs/images/everest_scale_horizontally.png b/docs/images/everest_scale_horizontally.png
diff --git a/docs/images/everest_scale_vertically_up.png b/docs/images/everest_scale_vertically_up.png
diff --git a/docs/images/operators_upgrade_dependency.png b/docs/images/operators_upgrade_dependency.png
diff --git a/docs/images/rbac_backup_permissions.png b/docs/images/rbac_backup_permissions.png
diff --git a/docs/images/rbac_cluster_permissions.png b/docs/images/rbac_cluster_permissions.png
diff --git a/docs/images/rbac_monitoring_permissions.png b/docs/images/rbac_monitoring_permissions.png
diff --git a/docs/images/rbac_readonly_ns.png b/docs/images/rbac_readonly_ns.png
diff --git a/docs/images/rbac_readonly_role.png b/docs/images/rbac_readonly_role.png
diff --git a/docs/images/rbac_storages_permissions.png b/docs/images/rbac_storages_permissions.png
diff --git a/docs/images/readonly_role_overview_page.png b/docs/images/readonly_role_overview_page.png
diff --git a/docs/images/sharding.png b/docs/images/sharding.png
diff --git a/docs/images/sharding_status.png b/docs/images/sharding_status.png
diff --git a/docs/images/show_operators_upgrades.png b/docs/images/show_operators_upgrades.png
diff --git a/docs/images/upgrade_buttons_page.png b/docs/images/upgrade_buttons_page.png
diff --git a/docs/images/upgrade_crd_confirmation.png b/docs/images/upgrade_crd_confirmation.png
diff --git a/docs/images/upgrade_dependency.png b/docs/images/upgrade_dependency.png
diff --git a/docs/images/upgrade_operators_confirmation.png b/docs/images/upgrade_operators_confirmation.png
diff --git a/docs/install/SetupPrereqs.md b/docs/install/SetupPrereqs.md
@@ -7,25 +7,25 @@ Percona Everest has two primary components:
 
 ## Supported operators
 
-* Percona Operator for MySQL Based on Percona XtraDB Cluster (PXC) 1.13.0, 1.14.0
+* Percona Operator for MySQL Based on Percona XtraDB Cluster (PXC) 1.14.0, 1.15.0
 * Percona Operator for MongoDB (PSMDB) 1.15.0
-* Percona Operator for PostgreSQL (PG) 2.3.1
+* Percona Operator for PostgreSQL (PG) 2.3.1, 2.4.1
 
 ## Supported k8s clusters
 
 Percona Everest works on most of the cloud K8s and on most of the on-prem vanilla K8s.
 
 However, not all the many combinations of K8s distributions and K8s versions might be fully tested and certified. Refer to the matrix below and [reach out to us](SetupPrereqs.md#get-expert-help) should you have any questions.
 
-| Platform              | Kubernetes Version | Percona Everest Version | State                                   |
-|:----------------------|:-------------------|:------------------------|:----------------------------------------|
-| Google GKE            | 1.24 - 1.28        | >= 1.0.0                | Fully tested and certified                |
-| Amazon EKS            | 1.24 - 1.28        | >= 1.0.0                | Fully tested and certified                |
-| Vanilla K8s (kubeadm) | 1.24 - 1.28        | >= 1.0.0                | Fully tested and certified                |
-| Azure AKS             | -                  | >= 1.0.0                | Works but not fully certified yet       |
-| DigitalOcean          | -                  | >= 1.0.0                | Works but not fully certified yet       |
-| OpenShift             | -                  |                         | Coming soon                             |
-| Other cloud K8s       | -                  |                         | Should work but not fully certified yet |
+| Platform              | Kubernetes Version | State                                   |
+|:----------------------|:-------------------|:----------------------------------------|
+| Google GKE            | 1.27 - 1.29        | Fully tested and certified                |
+| Amazon EKS            | 1.28 - 1.30        | Fully tested and certified                |
+| Azure AKS             | -                  | Works but not fully certified yet       |
+| DigitalOcean          | -                  | Works but not fully certified yet       |
+| Vanilla K8s (kubeadm) | -                  | Works but not fully certified yet       |
+| OpenShift             | -                  | Coming soon                             |
+| Other cloud K8s       | -                  | Should work but not fully certified yet |
 
 !!! note
     Air-gapped environments (i.e. environments physically isolated from unsecured networks such as the public Internet) are not currently supported. Their support is coming soon.

diff --git a/docs/install/installEverest.md b/docs/install/installEverest.md
@@ -55,15 +55,15 @@ To install and provision Percona Everest to Kubernetes:
 
 4. Access the Everest UI/API using one of the following options for exposing it, as Everest is not exposed with an external IP by default:
 
-    === "Service Type Load Balancer"
+    === "Load Balancer"
 
-        * Use the following command to change the Everest service type to `LoadBalancer`:
+        1. Use the following command to change the Everest service type to `LoadBalancer`:
 
             ```sh
             kubectl patch svc/everest -n everest-system -p '{"spec": {"type": "LoadBalancer"}}'
             ```
 
-        * Retrieve the external IP address for the Everest service. This is the address where you can then launch Everest at the end of the installation procedure. In this example, the external IP address used is the default `127.0.0.1`:  
+        2. Retrieve the external IP address for the Everest service. This is the address where you can then launch Everest at the end of the installation procedure. In this example, the external IP address used is [http://34.175.201.246](http://34.175.201.246): 
 
             ```sh 
             kubectl get svc/everest -n everest-system
@@ -72,14 +72,51 @@ To install and provision Percona Everest to Kubernetes:
             ??? example "Expected output"
                 ```
                 NAME      TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)          AGE
-                everest   LoadBalancer   10.43.172.194   127.0.0.1       8080:8080/TCP    10s
+                everest   LoadBalancer   10.43.172.194   34.175.201.246       8080:8080/TCP    10s
                 ```
 
+
+    === "Node Port"
+        A NodePort is a service that makes a specific port accessible on all nodes within the cluster. It enables external traffic to reach services running within the Kubernetes cluster by assigning a static port to each node's IP address.
+
+        1. Run the following command to change the Everest service type to `NodePort`:
+
+            ```sh
+            kubectl patch svc/everest -n everest-system -p '{"spec": {"type": "NodePort"}}
+            ```
+        2. The following command displays the port assigned by Kubernetes to the everest service, which is `32349` in this case.
+
+            ```sh
+            kubectl get svc/everest -n everest-system
+            NAME      TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
+            everest   NodePort   10.43.139.191   <none>        8080:32349/TCP   28m
+            ```
+
+        3. Retrieve the external IP addresses for the kubernetes cluster nodes.
+
+            ```sh
+            kubectl get nodes -o wide
+            NAME                   STATUS   ROLES    AGE   VERSION             
+            INTERNAL-IPEXTERNAL-IP  OS-IMAGE                        KERNEL-VERSION   
+            CONTAINER-RUNTIME
+            gke-everest-test-default-pool-8bbed860-65gx   Ready    <none>   3m35s   
+            v1.30.3-gke.1969001   10.204.15.199   34.175.155.135   Container- 
+            Optimized OS from Google   6.1.100+         containerd://1.7.19
+            gke-everest-test-default-pool-8bbed860-pqzb   Ready    <none>   3m35s   
+            v1.30.3-gke.1969001   10.204.15.200   34.175.120.50    Container- 
+            Optimized OS from Google   6.1.100+         containerd://1.7.19
+            gke-everest-test-default-pool-8bbed860-s0hg   Ready    <none>   3m35s   
+            v1.30.3-gke.1969001   10.204.15.201   34.175.201.246   Container- 
+            Optimized OS from Google   6.1.100+         containerd://1.7.19
+            ```
+
+        4. To launch the Percona Everest UI and create your first database cluster, go to the IP address/port found in steps 2 and 3. In this example, the external IP address used is [http://34.175.155.135:32349](http://34.175.155.135:32349). Nevertheless, you have the option to use any node IP specified in the above steps.
+
     === "Port Forwarding"
         Run the following command to use `Kubectl port-forwarding` for connecting to Everest without exposing the service:
 
         ```sh
         kubectl port-forward svc/everest 8080:8080 -n everest-system
         ``` 
 
-5. To launch the Everest UI and create your first database cluster, go to the IP address configured for the Everest service in step 4. In the example above, this is [http://127.0.0.1:8080](http://127.0.0.1:8080).
+        To launch the Percona Everest UI and create your first database cluster, go to your localhost IP address [http://127.0.0.1:8080](http://127.0.0.1:8080).
diff --git a/docs/quickstart-guide/quick-install.md b/docs/quickstart-guide/quick-install.md
@@ -98,32 +98,71 @@ You can download the latest version of Everest CLI by visiting the latest releas
         You can retrieve the automatically generated password by running the `everestctl accounts initial-admin-password` command. However, this password isn't stored securely.
 
 
-    For more information on user management, see the section [Manage users in Percona Everest](../manage_users.md).
+    For more information on user management, see the section [Manage users in Percona Everest](../administer/manage_users.md).
 
 4. Access the Everest UI/API using one of the following options for exposing it, as Everest is not exposed with an external IP by default:
 
-    === "Service Type Load Balancer"
+    === "Load Balancer"
 
-        * Use the following command to change the Everest service type to `LoadBalancer`:
+        1. Use the following command to change the Everest service type to `LoadBalancer`:
 
             ```sh
             kubectl patch svc/everest -n everest-system -p '{"spec": {"type": "LoadBalancer"}}'
             ```
 
-        * Retrieve the external IP address for the Everest service. This is the address where you can then launch Everest at the end of the installation procedure. In this example, the external IP address used is the default `127.0.0.1`:  
+        2. Retrieve the external IP address for the Everest service. This is the address where you can then launch Everest at the end of the installation procedure. In this example, the external IP address used is [http://34.175.201.246](http://34.175.201.246):
 
             ```sh 
             kubectl get svc/everest -n everest-system
             ```
 
+
+
+
+    === "Node Port"       
+
+        1. Run the following command to change the Everest service type to `NodePort`:
+
+            ```sh
+            kubectl patch svc/everest -n everest-system -p '{"spec": {"type": "NodePort"}}
+            ```
+
+        2. The following command displays the port assigned by Kubernetes to the everest service, which is `32349` in this case.
+
+            ```sh
+            kubectl get svc/everest -n everest-system
+            NAME      TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
+            everest   NodePort   10.43.139.191   <none>        8080:32349/TCP   28m
+            ```
+
+        3. Retrieve the external IP addresses for the kubernetes cluster nodes.
+
+            ```sh
+            kubectl get nodes -o wide
+            NAME                   STATUS   ROLES    AGE   VERSION             
+            INTERNAL-IPEXTERNAL-IP  OS-IMAGE                        KERNEL-VERSION   
+            CONTAINER-RUNTIME
+            gke-everest-test-default-pool-8bbed860-65gx   Ready    <none>   3m35s   
+            v1.30.3-gke.1969001   10.204.15.199   34.175.155.135   Container- 
+            Optimized OS from Google   6.1.100+         containerd://1.7.19
+            gke-everest-test-default-pool-8bbed860-pqzb   Ready    <none>   3m35s   
+            v1.30.3-gke.1969001   10.204.15.200   34.175.120.50    Container- 
+            Optimized OS from Google   6.1.100+         containerd://1.7.19
+            gke-everest-test-default-pool-8bbed860-s0hg   Ready    <none>   3m35s   
+            v1.30.3-gke.1969001   10.204.15.201   34.175.201.246   Container- 
+            Optimized OS from Google   6.1.100+         containerd://1.7.19
+            ```
+
+        4. To launch the Percona Everest UI and create your first database cluster, go to the IP address/port found in steps 2 and 3. In this example, the external IP address used is [http://34.175.155.135:32349](http://34.175.155.135:32349). Nevertheless, you have the option to use any node IP specified in the above steps.
+
     === "Port Forwarding"
         Run the following command to use `Kubectl port-forwarding` for connecting to Everest without exposing the service:
 
         ```sh
         kubectl port-forward svc/everest 8080:8080 -n everest-system
         ``` 
 
-    Percona Everest will be available at [http://127.0.0.1:8080](http://127.0.0.1:8080). 
+        Percona Everest will be available at [http://127.0.0.1:8080](http://127.0.0.1:8080). 
 
 
 ## Next steps

diff --git a/docs/reference/telemetry.md b/docs/reference/telemetry.md
@@ -14,46 +14,44 @@ Rest assured, access to the raw data is rigorously controlled, and individual us
 
 ## Disable telemetry
 
-Starting with Everest 0.4.1, telemetry is enabled by default. If you don't want to send usage data to Percona, you can set the **DISABLE_TELEMETRY** environment variable to TRUE:
+Starting with Everest 0.4.1, telemetry is enabled by default. If you don't want to send usage data to Percona, you can set the **DISABLE_TELEMETRY** environment variable to **TRUE**:
 {.power-number}
 
-1. When [installing Everest using the quick install script](../quickstart-guide/quick-install.md), set the `DISABLE_TELEMETRY` env variable to **True**: 
-
-      ```sh
-      export DISABLE_TELEMETRY=true
-      ```
+To disable telemetry run:
+
+```sh
+kubectl -n everest-system patch deployment percona-everest --type strategic -p 'spec:
+  strategy:
+    rollingUpdate:
+      maxSurge: 0
+      maxUnavailable: 1
+    type: RollingUpdate
+  template:
+    spec:
+      containers:
+        - name: everest
+          env:
+          - name: DISABLE_TELEMETRY
+            value: "true"'
+```
+
+## Enable telemetry
+
+If you want to enable telemetry again:
+
+```sh
+kubectl -n everest-system patch deployment percona-everest --type strategic -p 'spec:
+  strategy:
+    rollingUpdate:
+      maxSurge: 0
+      maxUnavailable: 1
+    type: RollingUpdate
+  template:
+    spec:
+      containers:
+        - name: everest
+          env:
+          - name: DISABLE_TELEMETRY
+            value: "false"'
+```
 
-2. Restart the Everest backend:
-
-    ```sh
-    docker compose -f quickstart.yml restart everest   
-    ```
-
-3. Run the Everest upgrade command so the underlying operators apply the new setting as well:
-
-    ```sh
-    ./everestctl upgrade
-    ```
-
-## Enable telemetry again
-
-To re-enable telemetry:
-{.power-number}
-
-1. Set the DISABLE_TELEMETRY environment variable to false: 
-
-    ```sh 
-    export DISABLE_TELEMETRY=false
-    ```
-
-2. Restart the Everest backend:
-
-    ```sh
-    docker compose -f quickstart.yml restart everest
-    ```
-
-3. Run the Everest provisioning again to make sure that the underlying operators apply the new setting as well:
-
-    ```sh
-    ./everestctl upgrade
-    ```
diff --git a/docs/release-notes/Percona-Everest-1.1.0-(2024-08-12).md b/docs/release-notes/Percona-Everest-1.1.0-(2024-08-12).md
@@ -138,7 +138,7 @@ curl -sS "https://raw.githubusercontent.com/percona/everest-doc/main/tools/bin/c
 
 What to do if you have schedules or backups that are using duplicated storages in different database technologies.
 
-=== ":simple-mongodb: MongoDB :simple-mysql: MySQL"
+=== ":simple-mongodb: MongoDB or :simple-mysql: MySQL"
 
     Create a new backup using a different backup storage. Then, delete the old schedules and backups that use the duplicated storage.