added secret

app-of-secretstores.yaml

@@ -0,0 +1,31 @@
+# Bootstrap Application, applied once by hand (like app-of-projects.yaml
+# and incubator/*.yaml) — ArgoCD can't sync its own entry points. Syncs
+# everything under secretstores/ so SecretStore/ClusterSecretStore objects
+# are GitOps-managed instead of a manual one-off kubectl apply. Mirrors
+# app-of-projects.yaml exactly, kept as a separate Application (not folded
+# into that one) since these are External Secrets Operator resources, not
+# ArgoCD ones — different concern, same pattern.
+#
+# Uses the built-in "default" project — no chicken-and-egg problem, same
+# reasoning as app-of-projects.yaml.
+apiVersion: argoproj.io/v1alpha1
+kind: Application
+metadata:
+  name: app-of-secretstores
+  namespace: argocd
+  finalizers:
+    - resources-finalizer.argocd.argoproj.io
+spec:
+  project: default
+  source:
+    repoURL: 'http://gitea.192.168.1.7.nip.io/mukul/devops-infra-argo-config.git'
+    targetRevision: main
+    path: secretstores
+    directory:
+      recurse: true
+  destination:
+    name: in-cluster
+    namespace: argocd
+  syncPolicy:
+    automated:
+      prune: true

secretstores/gitea-admin-credentials.yaml

@@ -0,0 +1,28 @@
+# Migrates gitea-admin-credentials from a manually kubectl-created Secret
+# to Vault-backed. Same keys (username, password) the gitea chart's
+# admin.existingSecret already expects — see
+# devops-infra-helm-charts/helm-overrides/k8s-admin-prd-ase1/gitea/custom-values.yaml.
+# creationPolicy: Owner (the default) means ESO adopts the existing Secret
+# in place rather than needing it deleted first.
+apiVersion: external-secrets.io/v1
+kind: ExternalSecret
+metadata:
+  name: gitea-admin-credentials
+  namespace: gitea
+spec:
+  refreshInterval: 1h
+  secretStoreRef:
+    name: vault-backend
+    kind: ClusterSecretStore
+  target:
+    name: gitea-admin-credentials
+    creationPolicy: Owner
+  data:
+    - secretKey: username
+      remoteRef:
+        key: gitea/admin
+        property: username
+    - secretKey: password
+      remoteRef:
+        key: gitea/admin
+        property: password

secretstores/vault-backend.yaml

@@ -0,0 +1,30 @@
+# Points External Secrets Operator at your Vault as a secrets backend.
+# Auth is via the Kubernetes auth method (see the vault CLI commands run
+# to set this up: `vault auth enable kubernetes`, the "external-secrets"
+# role bound to the external-secrets ServiceAccount) — no long-lived Vault
+# token stored anywhere; ESO authenticates dynamically using its own
+# ServiceAccount's projected token each time it needs to read a secret.
+#
+# server uses Vault's internal cluster-DNS Service name, not the ingress
+# host — this is pod-to-pod traffic, same reasoning as claude.md's
+# "Pending" note about Jenkins pushing to Harbor via
+# harbor-core.harbor.svc.cluster.local instead of going through Contour.
+# tls_disable is set in Vault's own listener config (lab only), so this is
+# http://, not https://.
+apiVersion: external-secrets.io/v1
+kind: ClusterSecretStore
+metadata:
+  name: vault-backend
+spec:
+  provider:
+    vault:
+      server: "http://vault.vault.svc.cluster.local:8200"
+      path: "secret"
+      version: "v2"
+      auth:
+        kubernetes:
+          mountPath: "kubernetes"
+          role: "external-secrets"
+          serviceAccountRef:
+            name: "external-secrets"
+            namespace: "external-secrets"