diff --git a/extra-manifests/priorityclass-high-priority.yaml b/extra-manifests/priorityclass-high-priority.yaml new file mode 100644 index 0000000..1cd25a1 --- /dev/null +++ b/extra-manifests/priorityclass-high-priority.yaml @@ -0,0 +1,13 @@ +# devops-helm-charts' generic app chart (1.0.0, in templates/deployment.yaml) +# hardcodes `priorityClassName: high-priority` on every Deployment it +# renders — no values toggle, unconditional. No such PriorityClass exists +# on this cluster, and a Pod referencing a nonexistent one gets hard- +# rejected by the API server at admission, not soft-failed. Simplest fix: +# just create it, rather than fork the chart's own template. +apiVersion: scheduling.k8s.io/v1 +kind: PriorityClass +metadata: + name: high-priority +value: 1000 +globalDefault: false +description: "For app workloads deployed via devops-helm-charts' generic chart, which hardcodes this class name." diff --git a/secretstores/argocd-jenkins-ci-token.yaml b/secretstores/argocd-jenkins-ci-token.yaml new file mode 100644 index 0000000..bc011af --- /dev/null +++ b/secretstores/argocd-jenkins-ci-token.yaml @@ -0,0 +1,31 @@ +# Token for the scoped jenkins-ci ArgoCD account (see +# argocd-admin-prd/custom-values.yaml's accounts.jenkins-ci) — lets Jenkins +# trigger a sync of demo-go-app as the pipeline's last step, matching +# devops-lib's real refresh_and_sync (argocd app sync --hard-refresh). +# +# Unlike every other credential in this repo, this one genuinely can't be +# generated declaratively — ArgoCD only issues account tokens via its own +# API/CLI, after the account already exists on a running instance. One-time +# setup, once argocd-admin-prd has synced with the account config above: +# kubectl -n argocd port-forward svc/argocd-admin-prd-argocd-server 8080:80 & +# argocd login localhost:8080 --insecure --username admin --password '' +# TOKEN=$(argocd account generate-token --account jenkins-ci) +# kubectl -n vault exec -i vault-0 -- vault kv put secret/argocd/jenkins-ci token="$TOKEN" +apiVersion: external-secrets.io/v1 +kind: ExternalSecret +metadata: + name: argocd-jenkins-ci-token + namespace: jenkins +spec: + refreshInterval: 1h + secretStoreRef: + name: vault-backend + kind: ClusterSecretStore + target: + name: argocd-jenkins-ci-token + creationPolicy: Owner + data: + - secretKey: token + remoteRef: + key: argocd/jenkins-ci + property: token diff --git a/secretstores/harbor-robot-dockerconfig.yaml b/secretstores/harbor-robot-dockerconfig.yaml new file mode 100644 index 0000000..8929209 --- /dev/null +++ b/secretstores/harbor-robot-dockerconfig.yaml @@ -0,0 +1,40 @@ +# Docker registry credentials for Jenkins to push to Harbor, as a proper +# kubernetes.io/dockerconfigjson secret (not a plain Opaque one) so it can +# be mounted straight at ~/.docker/config.json in the build container — +# docker push/pull read that format natively, no explicit `docker login` +# step needed in the pipeline itself. +# +# Vault-backed, same pattern as everything else. Put the robot account's +# credentials in first (create it in the Harbor UI: your CI project -> +# Robot Accounts -> New Robot Account, scoped to push+pull on that one +# project — Harbor shows the secret once, copy it immediately): +# kubectl -n vault exec -i vault-0 -- vault kv put secret/harbor/jenkins-robot \ +# username='robot$+' \ +# password='' +apiVersion: external-secrets.io/v1 +kind: ExternalSecret +metadata: + name: harbor-robot-dockerconfig + namespace: jenkins +spec: + refreshInterval: 1h + secretStoreRef: + name: vault-backend + kind: ClusterSecretStore + target: + name: harbor-robot-dockerconfig + creationPolicy: Owner + template: + type: kubernetes.io/dockerconfigjson + data: + .dockerconfigjson: | + {"auths":{"harbor-core.harbor.svc.cluster.local":{"username":"{{ .username }}","password":"{{ .password }}","auth":"{{ printf "%s:%s" .username .password | b64enc }}"}}} + data: + - secretKey: username + remoteRef: + key: harbor/jenkins-robot + property: username + - secretKey: password + remoteRef: + key: harbor/jenkins-robot + property: password