From 4719d0305f723035abd71040020551bb179f3361 Mon Sep 17 00:00:00 2001 From: Mukul Sharma Date: Mon, 31 Aug 2026 09:02:30 +0530 Subject: [PATCH] added secret --- app-of-secretstores.yaml | 31 +++++++++++++++++++++++ secretstores/gitea-admin-credentials.yaml | 28 ++++++++++++++++++++ secretstores/vault-backend.yaml | 30 ++++++++++++++++++++++ 3 files changed, 89 insertions(+) create mode 100644 app-of-secretstores.yaml create mode 100644 secretstores/gitea-admin-credentials.yaml create mode 100644 secretstores/vault-backend.yaml diff --git a/app-of-secretstores.yaml b/app-of-secretstores.yaml new file mode 100644 index 0000000..a912ce2 --- /dev/null +++ b/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 diff --git a/secretstores/gitea-admin-credentials.yaml b/secretstores/gitea-admin-credentials.yaml new file mode 100644 index 0000000..b930943 --- /dev/null +++ b/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 diff --git a/secretstores/vault-backend.yaml b/secretstores/vault-backend.yaml new file mode 100644 index 0000000..5a622ac --- /dev/null +++ b/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"