39 lines
1.4 KiB
YAML
39 lines
1.4 KiB
YAML
# 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 <root-token> >/dev/null &&
|
|
# vault kv put secret/toolshed/gitea token=<api 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
|