docs: access management default is NetBird + Keycloak; Teleport is deprecated

The README credited Teleport with unified access management, but the
current model runs cluster access over the NetBird mesh with Keycloak as
the SSO identity provider. Teleport stays available for existing setups;
both teleport chart READMEs now carry a deprecation banner.

Signed-off-by: Ashish Jaiswal <ashish@obmondo.com>

Author: ashish1099

README.md

@@ -122,7 +122,9 @@ and day-2 operations for every supported platform.
   handling of trivial alerts like disks filling up.
 - **Secrets in Git, safely**: [sealed-secrets](./argocd-helm-charts/sealed-secrets/README.md) encrypts secrets locally
   before they are committed to your config repository.
-- **Unified access management** through Teleport for Kubernetes, applications, and databases.
+- **Unified access management**: cluster access runs over the [NetBird](https://netbird.io/) mesh with
+  [Keycloak](https://www.keycloak.org/) as the SSO identity provider by default. Teleport remains available as an
+  optional, deprecated alternative.
 - **Cluster security**: NetworkPolicies enforce least privilege between applications and secure intra-cluster and
   ingress traffic.
 - **Lifecycle operations**: auto-scaling, backup and recovery, live migration of applications or whole clusters, major

argocd-helm-charts/teleport-cluster/README.md

@@ -4,11 +4,15 @@
 apps). This chart deploys the central Teleport proxy/auth cluster (`clusterName` in values.yaml, e.g.
 `teleport.obmondo.com`) that managed clusters join through.
 
+> **Deprecated:** Teleport is no longer KubeAid's default access layer — new clusters use the NetBird mesh with
+> Keycloak SSO instead. This chart remains available for existing setups.
+
 ## Why it's in KubeAid
 
-KubeAid uses Teleport as the access layer for managed clusters: instead of distributing raw kubeconfigs, each
-managed cluster runs the [`teleport-kube-agent`](../teleport-kube-agent/README.md) chart and joins this central
-cluster, so cluster access can be issued/revoked/audited from one place.
+KubeAid previously used Teleport as the access layer for managed clusters: instead of distributing raw
+kubeconfigs, each managed cluster runs the [`teleport-kube-agent`](../teleport-kube-agent/README.md) chart and
+joins this central cluster, so cluster access can be issued/revoked/audited from one place. On current clusters
+that role is filled by NetBird (mesh access) and Keycloak (SSO).
 
 ## Upgrade
 

argocd-helm-charts/teleport-kube-agent/README.md

@@ -4,10 +4,14 @@ This chart deploys the [Teleport](https://goteleport.com) kube-agent — a light
 cluster's Kubernetes API to the central [`teleport-cluster`](../teleport-cluster/README.md) (see `proxyAddr` in
 values.yaml), so operators access it through Teleport instead of a distributed kubeconfig.
 
+> **Deprecated:** Teleport is no longer KubeAid's default access layer — new clusters use the NetBird mesh with
+> Keycloak SSO instead. This chart remains available for existing setups.
+
 ## Why it's in KubeAid
 
-This is the per-managed-cluster half of KubeAid's Teleport-based access model: `teleport-cluster` runs the central
-proxy/auth service, and every managed cluster runs this agent to expose its API through it.
+This is the per-managed-cluster half of KubeAid's previous Teleport-based access model: `teleport-cluster` runs the
+central proxy/auth service, and every managed cluster runs this agent to expose its API through it. On current
+clusters that role is filled by NetBird (mesh access) and Keycloak (SSO).
 
 **NOTE: if there is no join-token secret, the pod would fail to start.**