docs: update docs for GCP implementation

Author: nusnewob

README.md

@@ -5,9 +5,9 @@
 
 <!-- omit from toc -->
 
-# CNOE Azure Reference Implementation
+# CNOE GCP Reference Implementation
 
-This repository provides a reference implementation for deploying Cloud Native Operations Enabler (CNOE) components on Azure Kubernetes Service (AKS) using GitOps principles.
+This repository provides a reference implementation for deploying Cloud Native Operations Enabler (CNOE) components on Google Kubernetes Engine (GKE) using GitOps principles.
 
 <!-- omit from toc -->
 
@@ -68,37 +68,39 @@ This repository provides a reference implementation for deploying Cloud Native O
 
 ## Important Notes
 
-- **Azure Resource Management**: This repository does not manage Azure infrastructure. AKS cluster and DNS zone must be provisioned separately using your organization's infrastructure management approach.
-- **Production Readiness**: The helper tasks in this repository are for creating Azure resources for demo purposes only. Any production deployments should follow enterprise infrastructure management practices.
+- **GCP Resource Management**: This repository does not manage GCP infrastructure. GKE cluster and Cloud DNS zone must be provisioned separately using your organization's infrastructure management approach.
+- **Production Readiness**: The helper tasks in this repository are for creating GCP resources for demo purposes only. Any production deployments should follow enterprise infrastructure management practices.
 - **Configuration Management**: All configuration is centralised in `config.yaml`. The `private/` directory is only for temporary files during development.
-- **Bootstrap Approach**: The installation uses a local Kind cluster to bootstrap the installation to the target AKS cluster. The Kind cluster can be deleted after installation is complete.
+- **Bootstrap Approach**: The installation uses a local Kind cluster to bootstrap the installation to the target GKE cluster. The Kind cluster can be deleted after installation is complete.
 
 ## Prerequisites
 
-### Required Azure Resources
+### Required GCP Resources
 
-Before using this reference implementation, you **MUST** have the following Azure resources already created and configured:
+Before using this reference implementation, you **MUST** have the following GCP resources already created and configured:
 
-1. **AKS Cluster** (1.27+) with:
-   - OIDC Issuer enabled (`--enable-oidc-issuer`)
-   - Workload Identity enabled (`--enable-workload-identity`)
+1. **GKE Cluster** (1.27+) with:
+   - Workload Identity enabled
    - Sufficient node capacity for all components
-     - For example, the demonstration AKS cluster created with the helper task `test:aks:create` has node pool with the node size set to `standard_d4alds_v6` by default
-2. **Azure DNS Zone**
-   - A registered domain with Azure DNS as the authoritative DNS service
+     - For example, a demonstration GKE cluster should have nodes with at least 4 vCPUs and 16GB memory
+2. **Cloud DNS Zone**
+   - A registered domain with Cloud DNS as the authoritative DNS service
+3. **GCP Secret Manager**
+   - A Secret Manager instance for storing configuration secrets and certificates
 
 > **Important**:
 >
-> - All Azure resources must be in the same subscription and resource group
-> - Azure Key Vault and Crossplane Workload Identity are **NO LONGER** prerequisites - they will be created automatically during installation
-> - These resources are prerequisites and must be provisioned using your organisation's preferred infrastructure management approach (Terraform, Bicep, ARM templates, etc.). The tasks in this repository that create Azure resources (`test:aks:create`, etc.) are helper functions for demonstration purposes only and are **NOT recommended for production deployments**.
+> - All GCP resources must be in the same project and region
+> - GCP Secret Manager and Crossplane Workload Identity are prerequisites for secure authentication
+> - These resources must be provisioned using your organisation's preferred infrastructure management approach (Terraform, Deployment Manager, gcloud CLI, etc.). The tasks in this repository that create GCP resources are helper functions for demonstration purposes only and are **NOT recommended for production deployments**.
 
-#### Setup Guidance for Azure Resources
+#### Setup Guidance for GCP Resources
 
-For setting up the prerequisite Azure resources, refer to the official Azure documentation:
+For setting up the prerequisite GCP resources, refer to the official GCP documentation:
 
-- [Create an AKS cluster](https://docs.microsoft.com/en-us/azure/aks/kubernetes-walkthrough)
-- [Azure DNS zones](https://docs.microsoft.com/en-us/azure/dns/)
+- [Create a GKE cluster](https://cloud.google.com/kubernetes-engine/docs/how-to/creating-a-zonal-cluster)
+- [Cloud DNS zones](https://cloud.google.com/dns/docs/zones)
+- [Secret Manager](https://cloud.google.com/secret-manager/docs)
 
 ### GitHub Integration Setup
 
@@ -135,18 +137,18 @@ Save the token value temporarily as you will need it when creating the `config.y
 
 ## Installation Flow
 
-The installation process follows this new pattern using a local Kind cluster as bootstrap:
+The installation process follows this pattern using a local Kind cluster as bootstrap:
 
 1. Configure your environment settings in `config.yaml`
-2. Set up Azure credentials in `private/azure-credentials.json`
+2. Set up GCP credentials (service account key)
 3. Run `task install` which:
    - Creates a local Kind cluster using the configuration in `kind.yaml`
    - Deploys components to Kind cluster via Helmfile as specified in `bootstrap-addons.yaml`
-   - Crossplane on Kind cluster connects to Azure and creates necessary cloud resources:
+   - Crossplane on Kind cluster connects to GCP and manages cloud resources:
      - Crossplane Workload Identity
-     - Azure Key Vault
+     - Secret Manager secrets
      - DNS records (`*.local.<domain>`) for observing local installation
-   - Deploys CNOE components to the target AKS cluster via ArgoCD
+   - Deploys CNOE components to the target GKE cluster via ArgoCD
 4. Monitor installation progress via local ArgoCD at `argocd.local.<domain>` and Crossplane at `crossplane.local.<domain>`
 5. Once installation is complete, the local Kind cluster is no longer needed
 
@@ -160,25 +162,25 @@ erDiagram
   "Taskfile" ||--o{ "Helmfile" : "3. deploys to Kind"
   "Helmfile" ||--o{ "ArgoCD (Kind)" : "4. installs locally"
   "ArgoCD (Kind)" ||--o{ "Crossplane (Kind)" : "5. installs"
-  "Crossplane (Kind)" ||--o{ "Azure Resources" : "6. creates"
-  "ArgoCD (Kind)" ||--o{ "AKS Cluster" : "7. deploys CNOE"
+  "Crossplane (Kind)" ||--o{ "GCP Resources" : "6. manages"
+  "ArgoCD (Kind)" ||--o{ "GKE Cluster" : "7. deploys CNOE"
 ```
 
 ## Security Notes
 
 - GitHub App credentials contain sensitive information - handle with care
-- Azure credentials are stored in `private/azure-credentials.json` (copy from your Azure credential)
-- Configuration secrets are stored in Azure Key Vault (created automatically)
-- Workload Identity is used for secure Azure authentication (created automatically)
+- GCP service account credentials should be handled securely
+- Configuration secrets are stored in GCP Secret Manager
+- Workload Identity is used for secure GCP authentication
 - TLS encryption is used for all external traffic
 
 ## Installation Steps
 
 ### Installation Requirements
 
-- **Azure CLI** (2.13+) with subscription access
+- **gcloud CLI** with project access
 - **kubectl** (1.27+)
-- **kubelogin** for AKS authentication
+- **gke-gcloud-auth-plugin** for GKE authentication
 - **yq** for YAML processing
 - **helm** (3.x)
 - **helmfile**
@@ -192,27 +194,31 @@ erDiagram
 Copy and customise the configuration:
 
 ```bash
-cp config.yaml.template config.yaml
+cp config.template.yaml config.yaml
 # Edit config.yaml with your values
 ```
 
-Set up Azure credentials:
+Set up GCP credentials:
 
 ```bash
-# Copy your Azure credentials to the private directory
-cp private/azure-credentials.template.json private/azure-credentials.json
-# Edit private/azure-credentials.json with your actual Azure credentials
+# Authenticate with GCP
+gcloud auth login
+gcloud config set project YOUR_PROJECT_ID
+
+# Create and download service account key if needed
+gcloud iam service-accounts keys create private/gcp-credentials.json \
+  --iam-account=YOUR_SERVICE_ACCOUNT@YOUR_PROJECT.iam.gserviceaccount.com
 ```
 
 Key configuration sections in `config.yaml`:
 
-- `repo`: The details of the repository hosting the reference azure implementation code
-- `cluster_name`: Your AKS cluster name
-- `subscription`: Your Azure subscription ID
-- `location`: The target Azure region
-- `resource_group`: Your Azure resource group
-- `cluster_oidc_issuer_url`: The AKS OIDC issuer URL
-- `domain`: The base domain name you will be using for exposing services
+- `repo`: The details of the repository hosting the reference GCP implementation code
+- `cluster_name`: Your GKE cluster name
+- `project`: Your GCP project ID
+- `region`: The target GCP region
+- `dns_zone`: Your Cloud DNS zone name
+- `dns_domain`: The base domain name you will be using for exposing services
+- `secret_manager`: GCP Secret Manager name for storing configuration secrets
 - `github`: GitHub App credentials (from the [Github Integration Setup](#github-integration-setup))
 
 #### DNS and TLS Configuration
@@ -245,7 +251,7 @@ task install
 
 > **Notes**:
 >
-> - `task install` will create a local Kind cluster and use it to bootstrap the installation to your AKS cluster
+> - `task install` will create a local Kind cluster and use it to bootstrap the installation to your GKE cluster
 > - Post-installation, use `task apply` (the equivalent to running `helmfile apply`) to apply updates. See the [Task Usage Guidelines](docs/TASKFILE.md) for more information.
 
 ### 3. Monitor Installation
@@ -263,22 +269,22 @@ During installation, you can monitor progress using the local Kind cluster:
 kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d
 ```
 
-Once the AKS installation is complete, you can also access ArgoCD on the target cluster:
+Once the GKE installation is complete, you can also access ArgoCD on the target cluster:
 
 ```bash
-# Switch to AKS cluster context
-task kubeconfig:set-context:aks
+# Switch to GKE cluster context
+task kubeconfig:set-context:gke
 
 # Get ArgoCD admin password
 kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d
 
-# Access ArgoCD (running on AKS cluster)
+# Access ArgoCD (running on GKE cluster)
 # Navigate to: https://argocd.<your-domain>
 ```
 
 ### 4. Get Access URLs
 
-Use the `task get:urls` command to fetch all the URLs from the target AKS cluster:
+Use the `task get:urls` command to fetch all the URLs from the target GKE cluster:
 
 ```bash
 task get:urls
@@ -302,11 +308,11 @@ The URL structure of the URLs will depend on the type of routing you set in the
 
 ### 5. Access Backstage
 
-Once the Keycloak and Backstage are installed on the target AKS cluster, check you can login to the Backstage UI with a default user:
+Once the Keycloak and Backstage are installed on the target GKE cluster, check you can login to the Backstage UI with a default user:
 
 ```bash
-# Switch to AKS cluster context
-task kubeconfig:set-context:aks
+# Switch to GKE cluster context
+task kubeconfig:set-context:gke
 
 # Get user password
 kubectl -n keycloak get secret keycloak-config -o yaml | yq '.data.USER1_PASSWORD | @base64d'
@@ -327,14 +333,14 @@ Backstage templates can be found in the `templates/` directory
 ## Uninstall
 
 ```bash
-# Remove all components and clean up Azure resources
+# Remove all components and clean up GCP resources
 task uninstall
 
 # Clean up GitHub App and tokens manually
 # Delete the GitHub organisation if no longer needed
 ```
 
-> **Note**: The `task uninstall` command will clean up both the local Kind cluster and remove CNOE components from the target AKS cluster. Azure resources created by Crossplane (Key Vault, Workload Identity) will also be cleaned up automatically.
+> **Note**: The `task uninstall` command will clean up both the local Kind cluster and remove CNOE components from the target GKE cluster. GCP resources managed by Crossplane will also be cleaned up automatically.
 
 ## Contributing
 
@@ -350,16 +356,17 @@ See [TROUBLESHOOTING.md](docs/TROUBLESHOOTING.md) for common issues and detailed
 
 ## Potential Enhancements
 
-The installation of this Azure reference implementation will give you a starting point for the platform, however as previously stated applications deployed in this repository are not meant or configured for production. To push it towards production ready, you can make further enhancements that could include:
+The installation of this GCP reference implementation will give you a starting point for the platform, however as previously stated applications deployed in this repository are not meant or configured for production. To push it towards production ready, you can make further enhancements that could include:
 
-1. Modifying the basic and Argo workflow templates for your specific Azure use cases
-2. Integrating additional Azure services with Crossplane
-3. Configuring auto-scaling for AKS and Azure resources
+1. Modifying the basic and Argo workflow templates for your specific GCP use cases
+2. Integrating additional GCP services with Crossplane (Cloud Storage, Cloud SQL, Pub/Sub, etc.)
+3. Configuring auto-scaling for GKE and GCP resources
 4. Adding OPA Gatekeeper for governance
 5. Integrating a monitoring stack. For example:
    1. Deploy Prometheus and Grafana
-   2. Configure service monitors for Azure resources
-   3. View metrics and Azure resource status in Backstage
+   2. Configure service monitors for GCP resources
+   3. View metrics and GCP resource status in Backstage
+   4. Integrate with Google Cloud Monitoring (formerly Stackdriver)
 6. Implementing GitOps-based environment promotion:
    1. **Development**: Deploy to dev environment via Git push
    2. **Testing**: Promote to test environment via ArgoCD

docs/DEMO.md

@@ -1,9 +1,11 @@
 <!-- omit from toc -->
-# Demo Guide - CNOE Azure Reference Implementation
 
-This guide demonstrates the key features and capabilities of the CNOE Azure Reference Implementation through practical examples focused on Azure services and infrastructure.
+# Demo Guide - CNOE GCP Reference Implementation
+
+This guide demonstrates the key features and capabilities of the CNOE GCP Reference Implementation through practical examples focused on GCP services and infrastructure.
 
 <!-- omit from toc -->
+
 ## Best Practices Demonstrated
 
 ### 1. GitOps Workflow
@@ -14,10 +16,10 @@ This guide demonstrates the key features and capabilities of the CNOE Azure Refe
 
 ### 2. Security
 
-- Workload Identity for Azure authentication
+- Workload Identity for GCP authentication
 - Secret management with External Secrets
 - TLS everywhere with cert-manager
-- Configuration stored securely in Azure Key Vault
+- Configuration stored securely in GCP Secret Manager
 
 ### 3. Developer Experience
 
@@ -33,6 +35,7 @@ This guide demonstrates the key features and capabilities of the CNOE Azure Refe
 - Centralized configuration management
 
 <!-- omit from toc -->
+
 ## Table of Contents
 
 - [Prerequisites](#prerequisites)
@@ -51,15 +54,15 @@ This guide demonstrates the key features and capabilities of the CNOE Azure Refe
 ## Prerequisites
 
 - Complete installation following the instructions in the [README.md](../README.md) file
-- All prerequisite Azure resources (AKS cluster, DNS zone, Key Vault) are properly configured
+- All prerequisite GCP resources (GKE cluster, Cloud DNS zone, Secret Manager) are properly configured
 - Access to Backstage UI at your configured domain
 - Default user (`user1`) credentials from Keycloak
 
 ## Getting Started: Explore the Platform
 
 After you installed the platform, before performing any operations/scenarios we recommend you first explore the platform.
 
-This section will provide you with instructions on you can access the UI for each component for you to explore. 
+This section will provide you with instructions on you can access the UI for each component for you to explore.
 
 To begin the `task get:urls` command can be used to fetch all the URLs.
 
@@ -123,7 +126,7 @@ See the [Backstage Documentation](https://backstage.io/docs/) for more informati
 
 ### Scenario 1: Creating a New Application from Template
 
-@TODO creating templates for Azure is still to be completed [link to issue to be attached]
+@TODO creating templates for GCP is still to be completed [link to issue to be attached]
 
 ## Reading Material
 
@@ -134,7 +137,7 @@ Previously linked reading material and more:
 - [Argo Workflows Examples](https://github.com/argoproj/argo-workflows/tree/master/examples)
 - [Crossplane Documentation](https://docs.crossplane.io/)
 - [CNOE Project](https://cnoe.io/)
-- [Azure Workload Identity](https://azure.github.io/azure-workload-identity/)
+- [GCP Workload Identity](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity)
 
 ## Feedback and Contributions