rewriting the backup page to include workload integration

Author: renetapopova

modules/ROOT/pages/kubernetes/operations/backup-restore.adoc

@@ -13,59 +13,28 @@ For more information, see xref:kubernetes/accessing-neo4j.adoc[Accessing Neo4j].
 
 You can perform a backup of a Neo4j database(s) to any cloud provider (AWS, GCP, and Azure) bucket using the _neo4j/neo4j-admin_ Helm chart.
 From Neo4j 5.10.0, the _neo4j/neo4j-admin_ Helm chart also supports performing a backup of multiple databases.
+And from 5.13.0, the _neo4j/neo4j-admin_ Helm chart also supports workload identity integration for GCP, AWS, and Azure.
 
 === Prerequisites
 
 Before you can back up a database and upload it to your bucket, verify that you have the following:
 
 * A cloud provider bucket (AWS, GCP, or Azure) with read and write access to be able to upload the backup.
 * Credentials to access the cloud provider bucket, such as a service account JSON key file for GCP, a credentials file for AWS, or storage account credentials for Azure.
+* A service account with workload identity if you want to use workload identity integration to access the cloud provider bucket.
+** For more information on setting up a service account with workload identity on GCP and AWS, see:
+*** link:https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity[Google Kubernetes Engine (GKE) -> Use Workload Identity]
+*** link:https://docs.aws.amazon.com/eks/latest/userguide/associate-service-account-role.html[Amazon EKS -> Configuring a Kubernetes service account to assume an IAM role]
+** For more information on setting up an Azure storage account with workload identity, link:https://learn.microsoft.com/en-us/azure/aks/workload-identity-overview?tabs=go[Microsoft Azure -> Use Microsoft Entra Workload ID with Azure Kubernetes Service (AKS)]
 * A Kubernetes cluster running on one of the cloud providers with the Neo4j Helm chart installed.
 For more information, see xref:kubernetes/quickstart-standalone/index.adoc[Quickstart: Deploy a standalone instance] or xref:kubernetes/quickstart-cluster/index.adoc[Quickstart: Deploy a cluster].
+* The latest Neo4j Helm charts.
+You can update the repository to get the latest charts using `helm repo update`.
 
-=== Steps
+=== Create a Kubernetes secret
 
-To perform a backup of a Neo4j database to any cloud provider (AWS, GCP, and Azure) bucket, follow these steps:
+You can create a Kubernetes secret with the credentials that can access the cloud provider bucket using one of the following options:
 
-. Update the repository to get the latest charts:
-+
-[source, shell, role='noheader']
-----
-helm repo update
-----
-. Configure the credentials to access the cloud provider bucket by either using a service account or a Kubernetes secret:
-+
-Service account::
-In some deployment situations, it may be desirable to assign a Kubernetes Service Account to the Neo4j pod.
-For example, if processes in the pod want to connect to services that require Service Account authorization.
-To configure the Neo4j pod to use a Kubernetes service account, set `podSpec.serviceAccountName` to the name of the service account to use.
-+
-For example:
-+
-[source, yaml]
-----
-# neo4j-values.yaml
-neo4j:
-  password: "my-password"
-
-podSpec:
-  serviceAccountName: "sa-name"
-----
-+
-[NOTE]
-====
-The service account must already exist.
-The Neo4j Helm chart does not create or configure Service Accounts.
-For more information on setting up a service account with workload identity, see the respective cloud provider documentation:
-
-* link:https://learn.microsoft.com/en-us/azure/aks/workload-identity-overview?tabs=go[Microsoft Azure -> Use Microsoft Entra Workload ID with Azure Kubernetes Service (AKS)]
-* link:https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity[Google Kubernetes Engine (GKE) -> Use Workload Identity]
-* link:https://docs.aws.amazon.com/eks/latest/userguide/associate-service-account-role.html[Amazon EKS -> Configuring a Kubernetes service account to assume an IAM role]
-====
-
-Kubernetes secret::
-Alternatively, you can create a Kubernetes secret with the credentials to access the cloud provider bucket using one of the following options:
-+
 [.tabbed-example]
 =====
 [.include-with-gke]
@@ -116,14 +85,105 @@ kubectl create secret generic azurecred --from-file=credentials=/path/to/your/cr
 ======
 =====
 
-. Configure the backup parameters in the _backup-values.yaml_ file by providing either `secretName` and `secretKeyName` or `serviceAccountName` as per your cloud provider:
-+
+=== Configure the backup parameters
+
+You can configure the backup parameters in the _backup-values.yaml_ file either by using the `secretName` and `secretKeyName` parameters or by mapping the Kubernetes service account
+to the workload identity integration.
+
 [NOTE]
 ====
 The following examples show the minimum configuration required to perform a backup to a cloud provider bucket.
 For more information about the available backup parameters, see <<kubernetes-neo4j-backup-parameters, Backup parameters>>.
 ====
-+
+
+==== Configure the _backup-values.yaml_ file using the `secretName` and `secretKeyName` parameters
+
+[.tabbed-example]
+=====
+[.include-with-gke]
+======
+[source, yaml, role='noheader']
+----
+neo4j:
+  image: "neo4j/helm-charts-backup"
+  imageTag: "5.10.0"
+  jobSchedule: "* * * * *"
+  successfulJobsHistoryLimit: 3
+  failedJobsHistoryLimit: 1
+  backoffLimit: 3
+
+backup:
+  bucketName: "my-bucket"
+  databaseAdminServiceName:  "standalone-admin" #This is the Neo4j Admin Service name.
+  database: "neo4j,system"
+  cloudProvider: "gcp"
+  secretName: "gcpcreds"
+  secretKeyName: "credentials"
+
+consistencyCheck:
+  enabled: true
+----
+======
+
+[.include-with-aws]
+======
+[source, yaml, role='noheader']
+----
+neo4j:
+  image: "neo4j/helm-charts-backup"
+  imageTag: "5.10.0"
+  jobSchedule: "* * * * *"
+  successfulJobsHistoryLimit: 3
+  failedJobsHistoryLimit: 1
+  backoffLimit: 3
+
+backup:
+  bucketName: "my-bucket"
+  databaseAdminServiceName:  "standalone-admin"
+  database: "neo4j,system"
+  cloudProvider: "aws"
+  secretName: "awscreds"
+  secretKeyName: "credentials"
+
+consistencyCheck:
+  enabled: true
+----
+======
+
+[.include-with-azure]
+======
+[source, yaml, role='noheader']
+----
+neo4j:
+  image: "neo4j/helm-charts-backup"
+  imageTag: "5.10.0"
+  jobSchedule: "* * * * *"
+  successfulJobsHistoryLimit: 3
+  failedJobsHistoryLimit: 1
+  backoffLimit: 3
+
+backup:
+  bucketName: "my-bucket"
+  databaseAdminServiceName:  "standalone-admin"
+  database: "neo4j,system"
+  cloudProvider: "azure"
+  secretName: "azurecreds"
+  secretKeyName: "credentials"
+
+consistencyCheck:
+  enabled: true
+----
+======
+=====
+
+==== Configure the _backup-values.yaml_ file using service account workload identity integration
+
+In some deployment situations, it may be desirable to assign a Kubernetes Service Account to the Neo4j backup pod.
+For example, if processes in the pod want to connect to services that require Service Account authorization.
+To configure the Neo4j backup pod to use a Kubernetes service account, set `serviceAccountName` to the name of the service account to use.
+For Azure deployments, you also need to set the `azureStorageAccountName` parameter to the name of the Azure storage account, where the backup files will be uploaded.
+For example:
+
 [.tabbed-example]
 =====
 [.include-with-gke]
@@ -133,6 +193,7 @@ For more information about the available backup parameters, see <<kubernetes-neo
 neo4j:
   image: "neo4j/helm-charts-backup"
   imageTag: "5.13.0"
+  serviceAccountName: "demo-service-account"
   jobSchedule: "* * * * *"
   successfulJobsHistoryLimit: 3
   failedJobsHistoryLimit: 1
@@ -143,9 +204,8 @@ backup:
   databaseAdminServiceName:  "standalone-admin" #This is the Neo4j Admin Service name.
   database: "neo4j,system"
   cloudProvider: "gcp"
-  #secretName: "gcpcreds"
-  #secretKeyName: "credentials"
-  #gcpServiceAccountName: "gcp-sa"
+  secretName: "gcpcreds"
+  secretKeyName: "credentials"
 
 consistencyCheck:
   enabled: true
@@ -159,6 +219,7 @@ consistencyCheck:
 neo4j:
   image: "neo4j/helm-charts-backup"
   imageTag: "5.13.0"
+  serviceAccountName: "demo-service-account"
   jobSchedule: "* * * * *"
   successfulJobsHistoryLimit: 3
   failedJobsHistoryLimit: 1
@@ -169,9 +230,8 @@ backup:
   databaseAdminServiceName:  "standalone-admin"
   database: "neo4j,system"
   cloudProvider: "aws"
-  #secretName: "awscreds"
-  #secretKeyName: "credentials"
-  #awsServiceAccountName: "aws-sa"
+  secretName: "awscreds"
+  secretKeyName: "credentials"
 
 consistencyCheck:
   enabled: true
@@ -185,6 +245,7 @@ consistencyCheck:
 neo4j:
   image: "neo4j/helm-charts-backup"
   imageTag: "5.13.0"
+  serviceAccountName: "demo-service-account"
   jobSchedule: "* * * * *"
   successfulJobsHistoryLimit: 3
   failedJobsHistoryLimit: 1
@@ -195,45 +256,30 @@ backup:
   databaseAdminServiceName:  "standalone-admin"
   database: "neo4j,system"
   cloudProvider: "azure"
-  #secretName: "azurecreds"
-  #secretKeyName: "credentials"
-  #azureStorageAccountName: "storageAccountName"
+  azureStorageAccountName: "storageAccountName"
 
 consistencyCheck:
   enabled: true
 ----
 ======
 =====
-+
 The _/backups_ mount created by default is an _emptyDir_ type volume.
 This means that the data stored in this volume is not persistent and will be lost when the pod is deleted.
 To use a persistent volume for backups add the following section to the _backup-values.yaml_ file:
-+
+
 [source, yaml, role='noheader']
 ----
 tempVolume:
   persistentVolumeClaim:
     claimName: backup-pvc
 ----
-+
+
 [NOTE]
 ====
 You need to create the persistent volume and persistent volume claim before installing the _neo4j-admin_ Helm chart.
 For more information, see xref:kubernetes/persistent-volumes.adoc[Volume mounts and persistent volumes].
 ====
 
-. Install _neo4j-admin_ Helm chart using the _backup-values.yaml_ file:
-+
-[source, shell, role='noheader']
-----
-helm install backup-name neo4j-admin -f /path/to/your/backup-values.yaml
-----
-+
-The _neo4j/neo4j-admin_ Helm chart installs a cronjob that launches a pod based on the job schedule. This pod performs a backup of one or multiple databases, a consistency check of the backup file(s),  and uploads them to the cloud provider bucket.
-
-. Monitor the backup pod logs using `kubectl logs pod/<neo4j-backup-pod-name>` to check the progress of the backup.
-. Check that the backup files and the consistency check reports have been uploaded to the cloud provider bucket.
-
 [[kubernetes-neo4j-backup-parameters]]
 === Backup parameters
 
@@ -438,6 +484,21 @@ tolerations: []
 #    effect: "NoSchedule"
 ----
 
+=== Install the _neo4j-admin_ Helm chart
+
+. Install _neo4j-admin_ Helm chart using the _backup-values.yaml_ file:
++
+[source, shell, role='noheader']
+----
+helm install backup-name neo4j-admin -f /path/to/your/backup-values.yaml
+----
++
+The _neo4j/neo4j-admin_ Helm chart installs a cronjob that launches a pod based on the job schedule.
+This pod performs a backup of one or multiple databases, a consistency check of the backup file(s),  and uploads them to the cloud provider bucket.
+
+. Monitor the backup pod logs using `kubectl logs pod/<neo4j-backup-pod-name>` to check the progress of the backup.
+. Check that the backup files and the consistency check reports have been uploaded to the cloud provider bucket.
+
 [[kubernetes-neo4j-restore]]
 == Restore a single database