From 48ecd1db7319f1fc732c884c561da784e7b5b60d Mon Sep 17 00:00:00 2001 From: Mukul Sharma Date: Sat, 5 Sep 2026 02:22:42 +0530 Subject: [PATCH] Add Gitea API token for toolshed's webhook management --- secretstores/toolshed-gitea-credentials.yaml | 38 ++++++++++++++++++++ 1 file changed, 38 insertions(+) create mode 100644 secretstores/toolshed-gitea-credentials.yaml diff --git a/secretstores/toolshed-gitea-credentials.yaml b/secretstores/toolshed-gitea-credentials.yaml new file mode 100644 index 0000000..a277bfd --- /dev/null +++ b/secretstores/toolshed-gitea-credentials.yaml @@ -0,0 +1,38 @@ +# Gitea API token for toolshed's builder, used to configure repository push +# webhooks so nobody has to add one by hand. +# +# builder holds this alongside its Jenkins credentials — it is the worker that +# talks to external systems. api deliberately holds neither: it is the most +# exposed service in the deployment, and keeping it unable to reach anything +# but its own database is the point of the split. +# +# Create the token in Gitea under Settings -> Applications -> Generate Token. +# Gitea 1.20 and later can scope tokens; write:repository is enough, and is +# considerably less than a full-access token. The account needs write access +# to the repositories toolshed will manage hooks on, so for repositories owned +# by one person their own token is the smallest thing that works. +# +# kubectl -n vault exec -i vault-0 -- sh -lc ' +# vault login >/dev/null && +# vault kv put secret/toolshed/gitea token=' +# +# Optional. Without it builder logs that webhooks must be added by hand and +# the dashboard says the same, rather than failing anything. +apiVersion: external-secrets.io/v1 +kind: ExternalSecret +metadata: + name: toolshed-gitea + namespace: toolshed +spec: + refreshInterval: 1h + secretStoreRef: + name: vault-backend + kind: ClusterSecretStore + target: + name: toolshed-gitea + creationPolicy: Owner + data: + - secretKey: token + remoteRef: + key: toolshed/gitea + property: token