diff --git a/applications/base/services/cert-manager/README.md b/applications/base/services/cert-manager/README.md
new file mode 100644
index 0000000..548f2d3
--- /dev/null
+++ b/applications/base/services/cert-manager/README.md
@@ -0,0 +1,14 @@
+# Cert-manager – Base Configuration
+
+This directory contains the **base manifests** for deploying [Cert-manager](https://cert-manager.io/). It is intended to be consumed by **cluster repositories** as a remote base, with the option to provide cluster-specific overrides.
+
+## Cert-Manager
+
+- Automates the management and renewal of TLS certificates in Kubernetes clusters.
+- Supports multiple certificate sources such as Let's Encrypt, HashiCorp Vault, and private PKI.
+- Uses custom resources like Issuer, ClusterIssuer, and Certificate to define how certificates are requested and managed.
+- Stores issued certificates and private keys securely in Kubernetes Secrets.
+- Handles ACME challenges, certificate revocation, and self-signed certificates.
+- Minimizes manual intervention and prevents downtime from expired certificates.
+- Commonly used to secure ingress controllers, internal services, and any workloads requiring TLS.
+- Simplifies certificate lifecycle management and enhances overall cluster security.
diff --git a/applications/base/services/external-snapshotter/README.md b/applications/base/services/external-snapshotter/README.md
new file mode 100644
index 0000000..f852de5
--- /dev/null
+++ b/applications/base/services/external-snapshotter/README.md
@@ -0,0 +1,14 @@
+# External-Snapshotter – Base Configuration
+
+This directory contains the **base manifests** for deploying the [External Snapshotter](https://kubernetes-csi.github.io/docs/snapshot-controller.html), a Kubernetes CSI component responsible for managing volume snapshots.  
+It is designed to be **consumed by cluster repositories** as a remote base, allowing each cluster to apply **custom overrides** as needed.
+
+**About External-Snapshotter:**
+
+- Provides Kubernetes-native APIs (`VolumeSnapshot`, `VolumeSnapshotContent`, and `VolumeSnapshotClass`) for managing persistent volume snapshots.  
+- Works with CSI drivers that support snapshot capabilities to create, restore, and delete snapshots.  
+- Consists of the **snapshot-controller**, **CRDs**, and **webhook** components.  
+- Enables backup, restore, and cloning workflows for persistent volumes.  
+- Decouples snapshot lifecycle management from storage vendors, offering a consistent interface across environments.  
+- Commonly used in backup automation, disaster recovery, and application data protection scenarios.  
+- Simplifies volume snapshot management and improves data resilience in Kubernetes clusters.  
diff --git a/applications/base/services/gateway-api/README.md b/applications/base/services/gateway-api/README.md
index 1323ec6..5718a3c 100644
--- a/applications/base/services/gateway-api/README.md
+++ b/applications/base/services/gateway-api/README.md
@@ -3,125 +3,10 @@
 This directory contains the **base manifests** for deploying the [Envoy Gateway](https://gateway.envoyproxy.io/) as a managed service.
 It is intended to be consumed by **cluster repositories** as a remote base, with the option to provide cluster-specific overrides.
 
-- `namespace.yaml` - Defines the `envoy-gateway-system` namespace.
-- `envoyproxy-source.yaml` - Defines the helm repository to install `envoy-gateway-api`.
-- `helmrelease.yaml` - FluxCD `HelmRelease` for deploying Envoy Gateway from the configured Helm repository.
-- `helm-values/hardened_values_v0.0.0.yaml` - Default “hardened” baseline values.
-  These are designed as production-ready defaults.
-- `kustomization.yaml` – Wires together the namespace, HelmRelease, and default values.
-  Also generates a `Secret` (`envoy-gateway-api-values-base`) from the hardened values.
+**About Envoy Gateway:**
 
-## Usage in a Cluster Repository
-
-A cluster repository should reference this base using a FluxCD `Kustomization` that points to the GitRepository containing this repo.
-
-Example `Kustomization` in the cluster repo:
-
-```yaml
----
-apiVersion: kustomize.toolkit.fluxcd.io/v1
-kind: Kustomization
-metadata:
-  name: envoy-gateway-api-base
-  namespace: flux-system
-spec:
-  interval: 1m
-  prune: true
-  sourceRef:
-    kind: GitRepository
-    name: opencenter-gateway-api #<= its the base flux gitrepository resource
-    namespace: flux-system
-  path: base/services/gateway-api
-  targetNamespace: envoy-gateway-system
-  wait: true
-```
-
-```yaml
-apiVersion: source.toolkit.fluxcd.io/v1
-kind: GitRepository
-metadata:
-  name: opencenter-gateway-api
-  namespace: flux-system
-spec:
-  interval: 1m
-  url: https://github.com/pratik705/opencenter1.git
-  ref:
-    branch: main
-```
-
-This will deploy Envoy Gateway with the default hardened configuration.
-
-## Overriding Values
-
-User can provide **cluster-specific overrides** without modifying this base.
-
-1. Create a folder in the cluster repo:
-
-   ```
-   applications/overlays/<cluster>/services/gateway-api/helm-values/
-   └── override_values.yaml
-   ```
-
-2. Reference both hardened values (from this base) and local overrides in a `Secret` (via `secretGenerator` or plain YAML). Example in cluster repo:
-
-```yaml
-namespace: envoy-gateway-system
-
-secretGenerator:
-  - name: envoy-gateway-api-values-override
-    namespace: envoy-gateway-system
-    type: Opaque
-    files:
-      - override.yaml=helm-values/override_values.yaml
-    options:
-      disableNameSuffixHash: true
-```
-
-3. The base HelmRelease is configured with `valuesFrom` so both hardened and override values are merged.
-   - Hardened defaults provide a secure baseline.
-   - Overrides take precedence when defined.
-
-## Example Override (cluster repo)
-
-`helm-values/override_values.yaml`:
-
-```yaml
-replicaCount: 2
-```
-
-This overrides replica count and service configuration while keeping the rest of the hardened defaults intact.
-
-## Adding Additional Resources
-
-User may also add **extra Kubernetes resources** (NetworkPolicies, ConfigMaps, etc.) alongside the override values.
-These will be applied together with the base and override.
-
-Example in cluster repo:
-
-```
-applications/overlays/<cluster>/services/gateway-api/
-├── helm-values/
-│   └── override_values.yaml
-├── networkpolicy.yaml
-├── opencenter-source.yaml
-└── kustomization.yaml
-```
-
-`kustomization.yaml:`
-
-```yaml
-namespace: envoy-gateway-system
-
-resources:
-  - "./opencenter-source.yaml"
-  - "./networkpolicy.yaml"
-
-secretGenerator:
-  - name: envoy-gateway-api-values-override
-    namespace: envoy-gateway-system
-    type: Opaque
-    files:
-      - override.yaml=helm-values/override_values.yaml
-    options:
-      disableNameSuffixHash: true
-```
+- Implements the Kubernetes **Gateway API** to manage north-south traffic routing for services.  
+- Simplifies Envoy deployment and configuration through a controller-based approach.
+- Integrates seamlessly with **Cert-Manager** for automatic TLS certificate provisioning.  
+- Supports advanced traffic management features such as path-based routing, header manipulation, timeouts, retries, and rate limiting.  
+- Commonly used to expose applications, APIs, and services securely to external clients.  
diff --git a/applications/base/services/harbor/README.md b/applications/base/services/harbor/README.md
new file mode 100644
index 0000000..d0f5f29
--- /dev/null
+++ b/applications/base/services/harbor/README.md
@@ -0,0 +1,14 @@
+# Harbor – Base Configuration
+
+This directory contains the **base manifests** for deploying [Harbor](https://goharbor.io/), a cloud-native registry that stores, signs, and scans container images and Helm charts.  
+It is designed to be **consumed by cluster repositories** as a remote base, allowing each cluster to apply **custom overrides** as needed.
+
+**About Harbor:**
+
+- Acts as a **secure and centralized container registry** for storing and managing OCI images and Helm charts.  
+- Provides **role-based access control(RBAC)** and **OIDC authentication** for user and project management.  
+- Supports **vulnerability scanning**, **image signing (Notary)**, and **content trust** to enhance supply chain security.  
+- Integrates with **Trivy** for image vulnerability scanning and **ChartMuseum** for Helm chart management.  
+- Can serve as a **private OCI registry** for GitOps workflows and Flux/Kustomize-based deployments.  
+- Features an intuitive web UI, REST API, and CLI tools for efficient image lifecycle management.  
+- Improves compliance, security, and performance for enterprise container environments.  
diff --git a/applications/base/services/headlamp/README.md b/applications/base/services/headlamp/README.md
index 8093ac2..731d4ac 100644
--- a/applications/base/services/headlamp/README.md
+++ b/applications/base/services/headlamp/README.md
@@ -1,15 +1,17 @@
-# Headlamp Kubernetes Dashboard with OIDC
+# Headlamp – Base Configuration
 
-This directory contains the Headlamp v0.35.0 Kubernetes dashboard configuration with OIDC authentication support for secure access to the cluster.
+This directory contains the **base manifests** for deploying [Headlamp](https://headlamp.dev/), a modern web-based Kubernetes dashboard built to simplify cluster management and visualization.  
+It is designed to be **consumed by cluster repositories** as a remote base, allowing each cluster to apply **custom overrides** as needed.
 
-## Overview
+**About Headlamp:**
 
-Headlamp is a Kubernetes web UI that provides:
-- Real-time cluster monitoring
-- Resource management capabilities
-- Plugin extensibility
-- OIDC authentication integration
-- Multi-cluster support
+- Provides an intuitive **web UI** for exploring and managing Kubernetes clusters.  
+- Supports **multi-cluster access**, RBAC-based authentication, and OIDC integration for secure user logins.  
+- Offers real-time insights into workloads, pods, services, storage, and cluster resources.  
+- Can be deployed both **in-cluster** or **externally** and accessed via an Ingress or LoadBalancer service.  
+- Enables plugin extensions and custom views for advanced integrations.  
+- Useful for developers, operators, and SREs who prefer a lightweight alternative to the classic Kubernetes Dashboard.  
+- Enhances troubleshooting and visibility without requiring kubectl access.  
 
 ## Architecture
 
@@ -46,627 +48,39 @@ Headlamp is a Kubernetes web UI that provides:
 
 1. Create a new client in your Keycloak realm
 2. Configure the client settings:
+
    ```
    Client ID: headlamp
    Client Protocol: openid-connect
    Access Type: confidential
-   Valid Redirect URIs: https://headlamp.example.com/*
-   Web Origins: https://headlamp.example.com
+   Valid Redirect URIs: https://headlamp.example.com/oidc-callback
    ```
+
 3. Note the client secret from the Credentials tab
 
 #### Required Scopes
 
 Ensure your OIDC provider supports these scopes:
+
 - `openid` - Required for OIDC
 - `profile` - User profile information
 - `email` - User email address
 - `groups` - User group membership (for RBAC)
 
-### Secret Configuration
-
-1. **Create the OIDC secret** using the template:
-
-   ```bash
-   # Copy and edit the template
-   cp applications/base/services/headlamp/oidc-secret-template.yaml /tmp/headlamp-oidc.yaml
-
-   # Edit with your OIDC provider details
-   nano /tmp/headlamp-oidc.yaml
-   ```
-
-2. **For production environments**, use sealed-secrets:
-
-   ```bash
-   # Create the secret and seal it
-   kubectl create secret generic headlamp-oidc-config \
-     --namespace kube-system \
-     --from-literal=clientID="your-client-id" \
-     --from-literal=clientSecret="your-client-secret" \
-     --from-literal=issuerURL="https://your-provider.com/realms/your-realm" \
-     --from-literal=scopes="openid profile email groups" \
-     --from-literal=callbackURL="https://headlamp.example.com/oidc-callback" \
-     --dry-run=client -o yaml | \
-   kubeseal -o yaml > applications/base/services/headlamp/sealed-oidc-secret.yaml
-   ```
-
-3. **Apply the secret**:
-
-   ```bash
-   kubectl apply -f /tmp/headlamp-oidc.yaml
-   # OR for sealed secrets:
-   kubectl apply -f applications/base/services/headlamp/sealed-oidc-secret.yaml
-   ```
-
-### Domain Configuration
-
-Update the ingress configuration in `helm-values/hardened-values-0.24.0.yaml`:
-
-```yaml
-ingress:
-  hosts:
-    - host: headlamp.your-domain.com  # Replace with your domain
-      paths:
-        - path: /
-          pathType: Prefix
-  tls:
-    - secretName: headlamp-tls
-      hosts:
-        - headlamp.your-domain.com
-```
-
-### RBAC Configuration
-
-Create appropriate RBAC permissions for OIDC users:
-
-```yaml
-# Example: Read-only access for developers
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRoleBinding
-metadata:
-  name: headlamp-developers
-roleRef:
-  apiGroup: rbac.authorization.k8s.io
-  kind: ClusterRole
-  name: view
-subjects:
-- kind: User
-  name: "developer@example.com"
-  apiGroup: rbac.authorization.k8s.io
-- kind: Group
-  name: "developers"
-  apiGroup: rbac.authorization.k8s.io
-```
-
-## Deployment
-
-### Quick Start Deployment Guide
-
-Follow these steps to deploy headlamp with OIDC authentication in your openCenter cluster:
-
-#### Step 1: Configure Your OIDC Provider
-
-First, set up your OIDC provider (Keycloak, Authentik, etc.) with the following settings:
-
-**Keycloak Example:**
-1. Create a new client in your Keycloak realm
-2. Configure client settings:
-   ```
-   Client ID: headlamp
-   Client Protocol: openid-connect
-   Access Type: confidential
-   Valid Redirect URIs: https://headlamp.YOUR-DOMAIN.com/*
-   Web Origins: https://headlamp.YOUR-DOMAIN.com
-   ```
-3. Save the client secret from the Credentials tab
-
-#### Step 2: Create the OIDC Secret
-
-Create the OIDC configuration secret using one of these methods:
-
-**Option A: Direct Secret Creation (Development)**
-```bash
-# Create the secret directly
-kubectl create secret generic headlamp-oidc-config \
-  --namespace kube-system \
-  --from-literal=clientID="your-client-id" \
-  --from-literal=clientSecret="your-client-secret" \
-  --from-literal=issuerURL="https://your-keycloak.com/realms/your-realm" \
-  --from-literal=scopes="openid profile email groups" \
-  --from-literal=callbackURL="https://headlamp.YOUR-DOMAIN.com/oidc-callback"
-```
-
-**Option B: Using Sealed Secrets (Production - Recommended)**
-```bash
-# 1. Copy and edit the secret template
-cp applications/base/services/headlamp/oidc-secret-template.yaml /tmp/headlamp-oidc.yaml
-
-# 2. Edit the secret with your values
-nano /tmp/headlamp-oidc.yaml
-
-# 3. Create and seal the secret
-kubectl create secret generic headlamp-oidc-config \
-  --namespace kube-system \
-  --from-literal=clientID="your-client-id" \
-  --from-literal=clientSecret="your-client-secret" \
-  --from-literal=issuerURL="https://your-keycloak.com/realms/your-realm" \
-  --from-literal=scopes="openid profile email groups" \
-  --from-literal=callbackURL="https://headlamp.YOUR-DOMAIN.com/oidc-callback" \
-  --dry-run=client -o yaml | \
-kubeseal -o yaml > applications/base/services/headlamp/sealed-oidc-secret.yaml
-
-# 4. Commit the sealed secret to Git
-git add applications/base/services/headlamp/sealed-oidc-secret.yaml
-git commit -m "Add headlamp OIDC sealed secret"
-```
-
-#### Step 3: Configure Your Domain
-
-Update the domain configuration in the hardened values:
-
-```bash
-# Edit the hardened values file
-nano applications/base/services/headlamp/helm-values/hardened-values-0.24.0.yaml
-
-# Replace all instances of "headlamp.example.com" with your actual domain
-# For example: "headlamp.cluster1.yourcompany.com"
-```
-
-**Required Changes:**
-```yaml
-ingress:
-  hosts:
-    - host: headlamp.YOUR-DOMAIN.com  # Update this
-      paths:
-        - path: /
-          pathType: Prefix
-  tls:
-    - secretName: headlamp-tls
-      hosts:
-        - headlamp.YOUR-DOMAIN.com    # Update this too
-```
-
-#### Step 4: Add to Your Cluster Configuration
-
-Include headlamp in your cluster's kustomization:
-
-```bash
-# Edit your cluster overlay
-nano applications/overlays/YOUR-CLUSTER/kustomization.yaml
-
-# Add headlamp to the resources list:
-resources:
-  - ../../base/services/cert-manager
-  - ../../base/services/ingress-nginx
-  - ../../base/services/headlamp        # Add this line
-  # ... other services
-```
-
-#### Step 5: Deploy via GitOps
-
-Commit and deploy your changes:
-
-```bash
-# Add all changes
-git add applications/base/services/headlamp/
-git add applications/overlays/YOUR-CLUSTER/kustomization.yaml
-
-# Commit changes
-git commit -m "Add headlamp with OIDC configuration"
-
-# Push to trigger Flux reconciliation
-git push origin main
-```
-
-#### Step 6: Monitor Deployment
-
-Watch the deployment progress:
-
-```bash
-# Monitor Flux reconciliation
-flux get helmreleases -n kube-system
-
-# Check headlamp pod status
-kubectl get pods -n kube-system -l app.kubernetes.io/name=headlamp
-
-# View deployment logs
-kubectl logs -n kube-system deployment/headlamp -f
-
-# Check ingress status
-kubectl get ingress headlamp -n kube-system
-```
-
-#### Step 7: Verify TLS Certificate
-
-Ensure cert-manager creates the TLS certificate:
-
-```bash
-# Check certificate status
-kubectl get certificate headlamp-tls -n kube-system
-
-# If certificate is not ready, check cert-manager logs
-kubectl logs -n cert-manager deployment/cert-manager -f
-```
-
-#### Step 8: Test Access
-
-1. Navigate to `https://headlamp.YOUR-DOMAIN.com`
-2. Click "Sign in with OIDC"
-3. Complete the OIDC authentication flow
-4. Verify you can access the Kubernetes dashboard
-
-### Alternative Deployment Methods
-
-#### Using Flux CD (Recommended)
-
-The GitOps approach above is the recommended method for production deployments.
-
-#### Manual Deployment (Development/Testing)
-
-For development or testing purposes, you can deploy manually:
-
-```bash
-# Ensure secret exists first
-kubectl get secret headlamp-oidc-config -n kube-system
-
-# Deploy using kubectl
-kubectl kustomize applications/base/services/headlamp | kubectl apply -f -
-
-# Monitor deployment
-kubectl get pods -n kube-system -l app.kubernetes.io/name=headlamp
-kubectl get helmrelease headlamp -n kube-system
-```
-
-### Post-Deployment Configuration
-
-#### Configure RBAC for Users
-
-Set up appropriate permissions for your OIDC users:
+### Cluster helm override values configuration
 
-```bash
-# Create a ClusterRoleBinding for developers (read-only access)
-kubectl apply -f - << EOF
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRoleBinding
-metadata:
-  name: headlamp-developers
-roleRef:
-  apiGroup: rbac.authorization.k8s.io
-  kind: ClusterRole
-  name: view
-subjects:
-- kind: User
-  name: "developer@yourcompany.com"
-  apiGroup: rbac.authorization.k8s.io
-- kind: Group
-  name: "developers"
-  apiGroup: rbac.authorization.k8s.io
-EOF
-
-# Create admin access for administrators
-kubectl apply -f - << EOF
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRoleBinding
-metadata:
-  name: headlamp-admins
-roleRef:
-  apiGroup: rbac.authorization.k8s.io
-  kind: ClusterRole
-  name: cluster-admin
-subjects:
-- kind: Group
-  name: "cluster-admins"
-  apiGroup: rbac.authorization.k8s.io
-EOF
-```
-
-#### Set Up Monitoring Alerts
-
-Configure alerts for headlamp availability:
-
-```bash
-# Example PrometheusRule for headlamp monitoring
-kubectl apply -f - << EOF
-apiVersion: monitoring.coreos.com/v1
-kind: PrometheusRule
-metadata:
-  name: headlamp-alerts
-  namespace: kube-system
-spec:
-  groups:
-  - name: headlamp
-    rules:
-    - alert: HeadlampDown
-      expr: up{job="headlamp"} == 0
-      for: 5m
-      labels:
-        severity: warning
-      annotations:
-        summary: "Headlamp is down"
-        description: "Headlamp has been down for more than 5 minutes"
-    - alert: HeadlampHighMemoryUsage
-      expr: container_memory_usage_bytes{pod=~"headlamp-.*"} / container_spec_memory_limit_bytes > 0.8
-      for: 10m
-      labels:
-        severity: warning
-      annotations:
-        summary: "Headlamp high memory usage"
-        description: "Headlamp memory usage is above 80%"
-EOF
-```
-
-### Validation Checklist
-
-After deployment, verify the following:
-
-- [ ] **Secret Created**: `kubectl get secret headlamp-oidc-config -n kube-system`
-- [ ] **Pods Running**: `kubectl get pods -n kube-system -l app.kubernetes.io/name=headlamp`
-- [ ] **Service Available**: `kubectl get service headlamp -n kube-system`
-- [ ] **Ingress Configured**: `kubectl get ingress headlamp -n kube-system`
-- [ ] **Certificate Ready**: `kubectl get certificate headlamp-tls -n kube-system`
-- [ ] **HelmRelease Deployed**: `kubectl get helmrelease headlamp -n kube-system`
-- [ ] **Web Interface Accessible**: Navigate to your domain
-- [ ] **OIDC Authentication Working**: Test login flow
-- [ ] **Kubernetes API Access**: Verify dashboard shows cluster resources
-- [ ] **RBAC Enforced**: Confirm users see appropriate resources
-
-### Environment-Specific Configurations
-
-#### Development Environment
-
-For development environments, you might want to:
-
-```yaml
-# Add to your dev overlay
-# applications/overlays/dev/headlamp-dev-values.yaml
-apiVersion: v1
-kind: Secret
-metadata:
-  name: headlamp-values-override
-  namespace: kube-system
-type: Opaque
-stringData:
-  override.yaml: |
-    replicaCount: 1
-    ingress:
-      annotations:
-        cert-manager.io/cluster-issuer: "letsencrypt-staging"
-    resources:
-      requests:
-        cpu: 50m
-        memory: 64Mi
-```
-
-#### Production Environment
-
-For production environments:
-
-```yaml
-# Add to your prod overlay
-# applications/overlays/prod/headlamp-prod-values.yaml
-apiVersion: v1
-kind: Secret
-metadata:
-  name: headlamp-values-override
-  namespace: kube-system
-type: Opaque
-stringData:
-  override.yaml: |
-    replicaCount: 3
-    resources:
-      requests:
-        cpu: 200m
-        memory: 256Mi
-      limits:
-        cpu: 1000m
-        memory: 1Gi
-    podDisruptionBudget:
-      minAvailable: 2
-```
-
-### Rollback Procedure
-
-If you need to rollback the deployment:
-
-```bash
-# Check Helm release history
-helm history headlamp -n kube-system
-
-# Rollback to previous version
-helm rollback headlamp -n kube-system
-
-# Or use Flux to rollback via Git
-git revert <commit-hash>
-git push origin main
-```
-
-This completes the deployment process for headlamp with OIDC authentication in your openCenter GitOps environment.
-
-## Access and Usage
-
-### Accessing Headlamp
-
-1. Navigate to `https://headlamp.your-domain.com`
-2. Click "Sign in with OIDC"
-3. Complete the OIDC authentication flow
-4. Access the Kubernetes dashboard
-
-### Features Available
-
-- **Cluster Overview**: Nodes, resources, and cluster status
-- **Workload Management**: Deployments, pods, services
-- **Configuration**: ConfigMaps, secrets, RBAC
-- **Storage**: PVs, PVCs, storage classes
-- **Networking**: Services, ingress, network policies
-- **Custom Resources**: CRDs and custom resources
-
-## Security Features
-
-### Network Security
-
-- **Network Policies**: Restrict ingress/egress traffic
-- **TLS Encryption**: All traffic encrypted in transit
-- **Security Headers**: Comprehensive HTTP security headers
-
-### Authentication & Authorization
-
-- **OIDC Integration**: Secure authentication via identity provider
-- **RBAC Integration**: Kubernetes RBAC enforcement
-- **Token Security**: ID tokens preferred over access tokens
-
-### Container Security
-
-- **Non-root execution**: Runs as non-privileged user
-- **Read-only filesystem**: Immutable container filesystem
-- **Security contexts**: Comprehensive security restrictions
-- **Capability dropping**: Minimal Linux capabilities
-
-## Monitoring
-
-### Health Checks
-
-```bash
-# Check pod status
-kubectl get pods -n kube-system -l app.kubernetes.io/name=headlamp
-
-# Check service endpoints
-kubectl get endpoints headlamp -n kube-system
-
-# Check ingress status
-kubectl get ingress headlamp -n kube-system
-```
-
-### Logs
-
-```bash
-# Application logs
-kubectl logs -n kube-system deployment/headlamp -f
-
-# Helm release status
-kubectl describe helmrelease headlamp -n kube-system
+``` yaml
+config:
+    oidc:
+        externalSecret:
+            enabled: false
+        secret:
+            create: true
+        clientID: opencenter
+        clientSecret: <REPLACEME>
+        issuerURL: https://auth.<account>.<env>.<region>.k8s.opencenter.cloud/realms/opencenter
+        scopes: openid profile email groups
+        callbackURL: https://headlamp.<account>.<env>.<region>.k8s.opencenter.cloud/oidc-callback
 ```
 
-## Troubleshooting
-
-### Common Issues
-
-#### OIDC Authentication Fails
-
-1. **Check secret configuration**:
-   ```bash
-   kubectl get secret headlamp-oidc-config -n kube-system -o yaml
-   ```
-
-2. **Verify OIDC provider settings**:
-   - Client ID and secret are correct
-   - Callback URL matches ingress configuration
-   - Required scopes are available
-
-3. **Check application logs**:
-   ```bash
-   kubectl logs -n kube-system deployment/headlamp
-   ```
-
-#### Ingress Issues
-
-1. **Verify cert-manager**:
-   ```bash
-   kubectl get certificate headlamp-tls -n kube-system
-   ```
-
-2. **Check ingress controller**:
-   ```bash
-   kubectl get ingress headlamp -n kube-system
-   kubectl describe ingress headlamp -n kube-system
-   ```
-
-#### Permission Denied
-
-1. **Check RBAC configurations**:
-   ```bash
-   kubectl auth can-i --list --as=system:serviceaccount:kube-system:headlamp
-   ```
-
-2. **Verify service account**:
-   ```bash
-   kubectl get serviceaccount headlamp -n kube-system
-   kubectl describe serviceaccount headlamp -n kube-system
-   ```
-
-### Debug Commands
-
-```bash
-# Force Flux reconciliation
-flux reconcile helmrelease headlamp -n kube-system
-
-# Check all resources
-kubectl get all -n kube-system -l app.kubernetes.io/name=headlamp
-
-# Test OIDC endpoint
-curl -k https://your-provider.com/realms/your-realm/.well-known/openid-configuration
-```
-
-## Customization
-
-### Adding Custom Plugins
-
-Mount plugin configurations via ConfigMaps:
-
-```yaml
-# Add to kustomization.yaml
-configMapGenerator:
-  - name: headlamp-plugins
-    files:
-      - plugins/my-plugin.js
-```
-
-### Environment-Specific Overrides
-
-Create overlay-specific configurations:
-
-```yaml
-# In applications/overlays/production/headlamp-values.yaml
-apiVersion: v1
-kind: Secret
-metadata:
-  name: headlamp-values-override
-  namespace: kube-system
-type: Opaque
-stringData:
-  override.yaml: |
-    replicaCount: 3
-    resources:
-      requests:
-        cpu: 200m
-        memory: 256Mi
-      limits:
-        cpu: 1000m
-        memory: 1Gi
-```
-
-## Maintenance
-
-### Updating Headlamp
-
-1. **Update chart version** in `helmrelease.yaml`
-2. **Update hardened values** filename to match new version
-3. **Test in development** environment first
-4. **Monitor deployment** after update
-
-### Backup Considerations
-
-- OIDC secret backup (store encrypted in secure location)
-- Custom plugin configurations
-- RBAC permissions for users/groups
-
-## Integration with openCenter
-
-Headlamp integrates with the openCenter GitOps platform:
-
-- **Keycloak SSO**: Uses the cluster's Keycloak instance for authentication
-- **cert-manager**: Automatic TLS certificate management
-- **Prometheus**: Metrics collection and monitoring
-- **Network Policies**: Integrated with cluster security policies
-- **Backup**: Included in Velero backup schedules
-
-For more information, see the [openCenter documentation](../../README.md).
+- Further manage the RBAC using `rbac-manager` service.
diff --git a/applications/base/services/headlamp/helm-values/hardened-values-0.24.0.yaml b/applications/base/services/headlamp/helm-values/hardened-values-0.24.0.yaml
deleted file mode 100644
index 011d814..0000000
--- a/applications/base/services/headlamp/helm-values/hardened-values-0.24.0.yaml
+++ /dev/null
@@ -1,152 +0,0 @@
-# Hardened values for headlamp v0.24.0
-# This file contains security-focused configurations for production deployment
-
-# Security contexts
-securityContext:
-  runAsNonRoot: true
-  seccompProfile:
-    type: RuntimeDefault
-
-containerSecurityContext:
-  allowPrivilegeEscalation: false
-  capabilities:
-    drop:
-      - ALL
-  readOnlyRootFilesystem: true
-
-# Node scheduling
-nodeSelector:
-  kubernetes.io/os: linux
-
-# Resource management
-resources:
-  requests:
-    cpu: 100m
-    memory: 128Mi
-  limits:
-    cpu: 500m
-    memory: 512Mi
-
-# High availability
-replicaCount: 2
-
-# Service account configuration
-serviceAccount:
-  create: true
-  automount: true  # Required for Kubernetes API access
-
-# OIDC Authentication Configuration
-# Using external secret approach for security
-config:
-  oidc:
-    # Use external secret for OIDC credentials
-    secret:
-      create: false
-    externalSecret:
-      enabled: true
-      name: headlamp-oidc-config
-    # Additional OIDC settings
-    scopes: "openid,profile,email,groups"
-    useAccessToken: false  # Use ID token for better security
-
-# Service configuration
-service:
-  type: ClusterIP
-  port: 80
-
-# Ingress configuration for OIDC callback
-ingress:
-  enabled: true
-  className: "nginx"
-  annotations:
-    cert-manager.io/cluster-issuer: "letsencrypt-prod"
-    nginx.ingress.kubernetes.io/ssl-redirect: "true"
-    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
-    # OIDC-specific security headers
-    nginx.ingress.kubernetes.io/configuration-snippet: |
-      more_set_headers "X-Frame-Options: DENY";
-      more_set_headers "X-Content-Type-Options: nosniff";
-      more_set_headers "X-XSS-Protection: 1; mode=block";
-      more_set_headers "Referrer-Policy: strict-origin-when-cross-origin";
-      more_set_headers "Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; font-src 'self'; connect-src 'self'";
-  hosts:
-    - host: headlamp.example.com  # Replace with your actual domain
-      paths:
-        - path: /
-          pathType: Prefix
-  tls:
-    - secretName: headlamp-tls
-      hosts:
-        - headlamp.example.com
-
-# Environment variables for OIDC
-env:
-  - name: HEADLAMP_OIDC_ENABLE
-    value: "true"
-
-# Network policies for security
-networkPolicy:
-  enabled: true
-  policyTypes:
-    - Ingress
-    - Egress
-  ingress:
-    - from:
-        - namespaceSelector:
-            matchLabels:
-              name: ingress-nginx
-        - podSelector:
-            matchLabels:
-              app.kubernetes.io/name: ingress-nginx
-      ports:
-        - protocol: TCP
-          port: 4466
-  egress:
-    # Allow DNS resolution
-    - to: []
-      ports:
-        - protocol: UDP
-          port: 53
-        - protocol: TCP
-          port: 53
-    # Allow HTTPS to OIDC provider
-    - to: []
-      ports:
-        - protocol: TCP
-          port: 443
-    # Allow Kubernetes API access
-    - to:
-        - namespaceSelector:
-            matchLabels:
-              name: kube-system
-      ports:
-        - protocol: TCP
-          port: 443
-
-# Pod disruption budget for high availability
-podDisruptionBudget:
-  enabled: true
-  minAvailable: 1
-
-# Additional security configurations
-podSecurityContext:
-  fsGroup: 65534
-  runAsGroup: 65534
-  runAsUser: 65534
-  runAsNonRoot: true
-  seccompProfile:
-    type: RuntimeDefault
-
-# Affinity for better distribution
-affinity:
-  podAntiAffinity:
-    preferredDuringSchedulingIgnoredDuringExecution:
-      - weight: 100
-        podAffinityTerm:
-          labelSelector:
-            matchExpressions:
-              - key: app.kubernetes.io/name
-                operator: In
-                values:
-                  - headlamp
-          topologyKey: kubernetes.io/hostname
diff --git a/applications/base/services/ingress-nginx/README.md b/applications/base/services/ingress-nginx/README.md
new file mode 100644
index 0000000..bc1a45c
--- /dev/null
+++ b/applications/base/services/ingress-nginx/README.md
@@ -0,0 +1,12 @@
+# NGINX Ingress Controller – Base Configuration
+
+This directory contains the **base manifests** for deploying the [NGINX Ingress Controller](https://kubernetes.github.io/ingress-nginx/), a Kubernetes-native ingress controller that manages external access to services within the cluster.  
+It is designed to be **consumed by cluster repositories** as a remote base, allowing each cluster to apply **custom overrides** as needed.
+
+**About NGINX Ingress Controller:**
+
+- Routes and load-balances external HTTP and HTTPS traffic to Kubernetes services using standard **Ingress** resources.  
+- Provides advanced traffic management features such as **path-based routing**, **SSL termination**, and **request/response annotations**.  
+- Supports integration with **Cert-Manager** for automatic TLS certificate provisioning and renewal.  
+- Enables detailed **metrics** and **access logging** for observability through Prometheus and Grafana.  
+- Commonly used as a secure entry point for applications, APIs, and internal services deployed on Kubernetes.  
diff --git a/applications/base/services/keycloak/README.md b/applications/base/services/keycloak/README.md
new file mode 100644
index 0000000..b66b890
--- /dev/null
+++ b/applications/base/services/keycloak/README.md
@@ -0,0 +1,15 @@
+# Keycloak – Base Configuration
+
+This directory contains the **base manifests** for deploying [Keycloak](https://www.keycloak.org/), an open-source identity and access management(IAM) solution that provides authentication, authorization, and single sign-on (SSO) capabilities for applications and services.  
+It is designed to be **consumed by cluster repositories** as a remote base, allowing each cluster to apply **custom overrides** as needed.
+
+**About Keycloak:**
+
+- Provides centralized **user authentication and authorization** for applications and APIs using OpenID Connect (OIDC) and SAML 2.0.  
+- Manages **users, roles, groups, and realms** through a web-based admin console or REST API.  
+- Supports **federated identity** integration with external identity providers such as Google, GitHub, or Microsoft Entra ID.  
+- Offers fine-grained access control through realm, client, and user configurations.  
+- Enables **token-based authentication** for Kubernetes and cloud-native workloads.  
+- Deployed via **Operator Lifecycle Manager(OLM)**, which automates the installation and lifecycle management of the Keycloak operator and its CRDs.  
+- Configured to use an **external PostgreSQL database** managed by the **Zalando Postgres Operator**, ensuring high availability, automated backups, and seamless scaling.  
+- Commonly used for securing Kubernetes dashboards, APIs, and internal services with OIDC-based authentication.
diff --git a/applications/base/services/kube-prometheus-stack/README.md b/applications/base/services/kube-prometheus-stack/README.md
new file mode 100644
index 0000000..3003f07
--- /dev/null
+++ b/applications/base/services/kube-prometheus-stack/README.md
@@ -0,0 +1,14 @@
+# Kube Prometheus Stack – Base Configuration
+
+This directory contains the **base manifests** for deploying the [Kube Prometheus Stack](https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack), a comprehensive Kubernetes monitoring solution that bundles **Prometheus**, **Alertmanager**, **Grafana**, and related exporters.  
+It is designed to be **consumed by cluster repositories** as a remote base, allowing each cluster to apply **custom overrides** as needed.
+
+**About Kube Prometheus Stack:**
+
+- Provides a fully integrated monitoring stack for **Kubernetes clusters and workloads**.  
+- Includes **Prometheus Operator** for managing Prometheus, Alertmanager, and related monitoring resources declaratively.  
+- Deploys **Grafana** with preconfigured dashboards for nodes, pods, networking, and application metrics.  
+- Automatically discovers targets and scrapes metrics using **ServiceMonitor** and **PodMonitor** CRDs.  
+- Integrates with **Alertmanager** for alert routing, notification management, and on-call workflows.  
+- Supports **custom alerting rules**, **recording rules**, and **Prometheus remote write** configurations.  
+- Commonly used to gain real-time visibility into cluster performance, resource utilization, and application health.  
diff --git a/applications/base/services/metallb/README.md b/applications/base/services/metallb/README.md
new file mode 100644
index 0000000..4d6e191
--- /dev/null
+++ b/applications/base/services/metallb/README.md
@@ -0,0 +1,14 @@
+# MetalLB – Base Configuration
+
+This directory contains the **base manifests** for deploying [MetalLB](https://metallb.universe.tf/), a load-balancer implementation for bare-metal Kubernetes clusters.  
+It is designed to be **consumed by cluster repositories** as a remote base, allowing each cluster to apply **custom overrides** as needed.
+
+**About MetalLB:**
+
+- Provides **LoadBalancer service functionality** in environments without a native cloud load balancer (such as bare-metal or on-premise clusters).  
+- Supports both **Layer 2** and **Layer 3** modes for flexible traffic routing.  
+- Allows assigning external IPs to Kubernetes services to make them accessible outside the cluster.  
+- Can advertise service IPs to upstream routers, enabling real network integration with minimal complexity.  
+- Works seamlessly with ingress controllers and gateways such as **NGINX**, **Envoy Gateway**, or **HAProxy**.  
+- Commonly used in hybrid or on-prem environments to provide reliable, production-grade service exposure.  
+- Simplifies network configuration and improves accessibility for Kubernetes workloads in non-cloud environments.  
diff --git a/applications/base/services/olm/README.md b/applications/base/services/olm/README.md
new file mode 100644
index 0000000..ac425ec
--- /dev/null
+++ b/applications/base/services/olm/README.md
@@ -0,0 +1,14 @@
+# Operator Lifecycle Manager (OLM) – Base Configuration
+
+This directory contains the **base manifests** for deploying the [Operator Lifecycle Manager (OLM)](https://olm.operatorframework.io/), a Kubernetes component that helps manage the installation, upgrade, and lifecycle of Operators.  
+It is designed to be **consumed by cluster repositories** as a remote base, allowing each cluster to apply **custom overrides** as needed.
+
+**About OLM:**
+
+- Simplifies the **deployment and management of Operators** in Kubernetes clusters.  
+- Provides a consistent framework for installing, upgrading, and uninstalling Operators using declarative resources.  
+- Introduces core custom resources such as **ClusterServiceVersion (CSV)**, **CatalogSource**, **Subscription**, and **OperatorGroup**.  
+- Supports **dependency resolution** between Operators to ensure smooth upgrades and compatibility.  
+- Allows hosting and consuming **Operator catalogs** from internal or external registries.  
+- Enables cluster administrators to control Operator permissions and namespace scopes securely.
+- Improves operational consistency and reduces manual intervention in Operator lifecycle management.  
diff --git a/applications/base/services/openstack-ccm/README.md b/applications/base/services/openstack-ccm/README.md
new file mode 100644
index 0000000..a224865
--- /dev/null
+++ b/applications/base/services/openstack-ccm/README.md
@@ -0,0 +1,13 @@
+# OpenStack Cloud Controller Manager (CCM) – Base Configuration
+
+This directory contains the **base manifests** for deploying the [OpenStack Cloud Controller Manager(CCM)](https://github.com/kubernetes/cloud-provider-openstack), which integrates Kubernetes with OpenStack cloud services for networking, storage, and instance management.  
+It is designed to be **consumed by cluster repositories** as a remote base, allowing each cluster to apply **custom overrides** as needed.
+
+**About OpenStack Cloud Controller Manager:**
+
+- Enables Kubernetes to interact directly with **OpenStack APIs** for managing cloud resources.  
+- Handles Kubernetes **node lifecycle management**, such as attaching instance metadata and updating node addresses.  
+- Provides **LoadBalancer service integration** by provisioning OpenStack **Octavia** load balancers.  
+- Updates node routes and network configurations in coordination with OpenStack **Neutron**.  
+- Commonly used in private or hybrid cloud environments where Kubernetes clusters run on OpenStack infrastructure.  
+- Improves automation, consistency, and observability of Kubernetes workloads on OpenStack-based platforms.  
diff --git a/applications/base/services/openstack-csi/README.md b/applications/base/services/openstack-csi/README.md
new file mode 100644
index 0000000..6ac4d42
--- /dev/null
+++ b/applications/base/services/openstack-csi/README.md
@@ -0,0 +1,13 @@
+# OpenStack Cinder CSI Driver – Base Configuration
+
+This directory contains the **base manifests** for deploying the [OpenStack Cinder CSI Driver](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/cinder-csi-plugin/using-cinder-csi-plugin.md), which integrates Kubernetes with OpenStack's block storage service(Cinder) to provide dynamic volume provisioning.  
+It is designed to be **consumed by cluster repositories** as a remote base, allowing each cluster to apply **custom overrides** as needed.
+
+**About OpenStack Cinder CSI Driver:**
+
+- Enables Kubernetes workloads to use **OpenStack Cinder volumes** as persistent storage.  
+- Supports **dynamic provisioning**, **expansion**, **snapshotting**, and **cloning** of volumes.  
+- Integrates with the **External Snapshotter** for snapshot and restore operations.  
+- Works in conjunction with the **OpenStack Cloud Controller Manager (CCM)** for seamless resource coordination.  
+- Securely manages volume credentials through **Kubernetes Secrets** and **OpenStack credentials** configuration.  
+- Commonly used in OpenStack-based Kubernetes clusters to provide scalable, high-performance, and fault-tolerant persistent storage.  
diff --git a/applications/base/services/postgres-operator/README.md b/applications/base/services/postgres-operator/README.md
new file mode 100644
index 0000000..5bbae3a
--- /dev/null
+++ b/applications/base/services/postgres-operator/README.md
@@ -0,0 +1,14 @@
+# Zalando Postgres Operator – Base Configuration
+
+This directory contains the **base manifests** for deploying the [Zalando Postgres Operator](https://github.com/zalando/postgres-operator), a Kubernetes operator that automates the management of PostgreSQL clusters.  
+It is designed to be **consumed by cluster repositories** as a remote base, allowing each cluster to apply **custom overrides** as needed.
+
+**About Zalando Postgres Operator:**
+
+- Automates the **provisioning, scaling, and maintenance** of PostgreSQL database clusters on Kubernetes.  
+- Manages **Postgres instances, replicas, and failover** automatically to ensure high availability.  
+- Supports **rolling updates**, **configuration changes**, and **PostgreSQL version upgrades** with minimal downtime.
+- Exposes declarative APIs (`postgresql` custom resources) to define database clusters and configurations.  
+- Integrates seamlessly with applications such as **Keycloak** or other services requiring external databases.  
+- Commonly used in production-grade environments for managing secure and self-healing PostgreSQL clusters.  
+- Simplifies database lifecycle management and reduces operational overhead in cloud-native environments.  
diff --git a/applications/base/services/sealed-secrets/README.md b/applications/base/services/sealed-secrets/README.md
new file mode 100644
index 0000000..02a0832
--- /dev/null
+++ b/applications/base/services/sealed-secrets/README.md
@@ -0,0 +1,14 @@
+# Sealed Secrets – Base Configuration
+
+This directory contains the **base manifests** for deploying [Sealed Secrets](https://github.com/bitnami-labs/sealed-secrets), a Kubernetes controller and CLI tool that allows storing encrypted secrets safely in Git repositories.  
+It is designed to be **consumed by cluster repositories** as a remote base, allowing each cluster to apply **custom overrides** as needed.
+
+**About Sealed Secrets:**
+
+- Enables **GitOps-friendly secret management** by encrypting Kubernetes secrets into SealedSecrets, which can be safely committed to version control.  
+- Uses a **controller running in the cluster** to decrypt SealedSecrets and generate standard Kubernetes Secrets.  
+- Ensures that only the controller(with access to the private key) can decrypt the data, maintaining confidentiality even if the repository is public.  
+- Supports both **namespace-scoped** and **cluster-wide** encryption keys.  
+- Allows secret rotation and re-encryption without exposing sensitive values in plaintext.  
+- Commonly used to manage credentials, API keys, and tokens securely in GitOps-managed clusters.  
+- Simplifies secret management workflows while maintaining strong encryption and operational security.  
diff --git a/applications/base/services/velero/README.md b/applications/base/services/velero/README.md
new file mode 100644
index 0000000..b040540
--- /dev/null
+++ b/applications/base/services/velero/README.md
@@ -0,0 +1,16 @@
+# Velero – Base Configuration
+
+This directory contains the **base manifests** for deploying [Velero](https://velero.io/), an open-source tool for **backup, restore, and disaster recovery** of Kubernetes clusters and persistent volumes.  
+It is designed to be **consumed by cluster repositories** as a remote base, allowing each cluster to apply **custom overrides** as needed.
+
+**About Velero:**
+
+- Provides **backup and restore** capabilities for Kubernetes resources, namespaces, and persistent volumes.  
+- Supports **scheduled backups**, **on-demand restores**, and **disaster recovery** across clusters or environments.  
+- Integrates with multiple storage backends, including **S3-compatible object storage**.
+- Uses **BackupStorageLocation** and **VolumeSnapshotLocation** custom resources to manage backup targets and configurations.  
+- Works seamlessly with **CSI snapshotters**(such as External Snapshotter) for volume-level backups.  
+- Enables **migration of workloads** between clusters by restoring backups into new environments.  
+- Supports encryption, retention policies, and incremental backups for efficient and secure data protection.  
+- Commonly used to safeguard production workloads and ensure recoverability in hybrid or multi-cluster Kubernetes deployments.  
+- Simplifies cluster recovery workflows and enhances operational resilience.  
diff --git a/applications/base/services/weave-gitops/README.md b/applications/base/services/weave-gitops/README.md
new file mode 100644
index 0000000..e6ffc71
--- /dev/null
+++ b/applications/base/services/weave-gitops/README.md
@@ -0,0 +1,12 @@
+# Weave GitOps Dashboard – Base Configuration
+
+This directory contains the **base manifests** for deploying the [Weave GitOps Dashboard](https://docs.gitops.weaveworks.org/), a web-based UI for managing and visualizing GitOps workflows powered by Flux.  
+It is designed to be **consumed by cluster repositories** as a remote base, allowing each cluster to apply **custom overrides** as needed.
+
+**About Weave GitOps Dashboard:**
+
+- Provides a **web UI** to visualize and manage Flux-based GitOps deployments in Kubernetes clusters.  
+- Displays **real-time status** of Flux resources such as GitRepositories, Kustomizations, and HelmReleases.  
+- Simplifies monitoring of sync health, drift detection, and reconciliation events across multiple environments.  
+- Offers deployment insights and audit-friendly visibility for platform and application teams.  
+- Improves GitOps adoption by providing a user-friendly interface for cluster and application management.