Updated phase6.md

docs/phases/phase6.md

@@ -2,38 +2,48 @@
 
 ## 1. Planned Improvements
 
-### 1.1 Architecture Update
-We plan to update the architecture diagram to provide a more accurate representation of:
+### 1.1 Ingress/API gateway configuration
 
-* The internal communication between microservices via gRPC.
-* The gRPC Gateway responsible for converting REST requests to gRPC.
-* The ingress flow, now using GKE’s native Ingress controller instead of Traefik.
+Currently, we are using Traefik with a basic IngressRoute and minimal configuration. To improve flexibility and take advantage of Kubernetes-native features, we will explore two alternatives:
 
-### 1.2 Migration to GKE Ingress
-To simplify deployment and maintenance, we will remove the Traefik Ingress Controller and adopt the native GKE Ingress. This improves integration with GCP’s load balancing.
+- **Kubernetes Ingress with Traefik:** This allows using standard Ingress resources with Traefik's CRDs for fine-grained traffic routing, TLS termination, and middleware chaining.
 
-### 1.3 Authentication with Keycloak
-We will introduce authentication and authorization by integrating [Keycloak](https://www.keycloak.org/) as the Identity Provider. Keycloak will manage user sessions, tokens (OIDC), and role-based access control (RBAC) across the services.
-
-### 1.4 CI/CD Pipeline
-A continuous integration and deployment (CI/CD) pipeline will be implemented using GitHub Actions and GKE. It will:
+- **Kubernetes Gateway API:** A more expressive and extensible alternative to the Ingress API, which decouples traffic routing from infrastructure. We'll experiment with it alongside Traefik's Gateway API support to modernize our networking layer.
 
-* Update OpenAPI specification files.
-* Build images.
-* Deploy services to the cluster.
-
-### 1.5 Liveness and Readiness Probes
+### 1.2 Liveness and Readiness Probes
 To improve fault tolerance and enable better self-healing behavior in Kubernetes, we will define:
 
 * **Liveness probes** to detect and restart failed containers.
 * **Readiness probes** to ensure that traffic is only sent to containers that are ready to handle requests.
 
-### 1.6 Resource Limits and HPA
+### 1.3 Resource Limits and HPA
 We will benchmark services to determine ideal values for:
 
 * **CPU and memory resource requests/limits**.
 * **Horizontal Pod Autoscaling (HPA)** thresholds to ensure scalability based on real traffic patterns.
 
+### 1.4 Authentication with Keycloak
+We will introduce authentication and authorization by integrating [Keycloak](https://www.keycloak.org/) as the Identity Provider. Keycloak will manage user sessions, tokens (OIDC), and role-based access control (RBAC) across the services.
+
+### 1.5 Secret management
+
+To further improve security we will explore Google Secret Manager for managing sensitive configuration data such as API keys, credentials, and tokens. This approach provides:
+
+- Centralized and secure secret storage.
+
+- IAM-based access control.
+
+- Seamless integration with GKE via workload identity.
+
+- Versioning and audit logging for secret access.
+
+### 1.6 CI/CD Pipeline
+A continuous integration and deployment (CI/CD) pipeline will be implemented using GitHub Actions and GKE. It will:
+
+* Update OpenAPI specification files.
+* Build images.
+* Deploy services to the cluster.
+
 ## 2. Non-Functional Requirements
 | Category        | Requirement                                                                |
 | --------------- | -------------------------------------------------------------------------- |