Conversation
Charts now render from https://stats-github.ever.works/svg instead of the shared public api.star-history.com, so they are backed by our own GitHub PAT quota and our own uptime, and are cached for 24h at the edge. Also fixes the repo name: the chart pointed at ever-co/directory-web-template, which is not this repo (it lives in ever-works). README-only change, so [skip ci] keeps it off the build runners. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…tl apply (#1006) Both secret-creating steps in deploy_k8s.yaml piped into a plain `kubectl apply -f -`. Client-side apply stamps the entire object into a `kubectl.kubernetes.io/last-applied-configuration` annotation, so for a Secret the payload ends up a second time, in cleartext-base64, in the object's METADATA - where it leaks through `-o yaml` dumps, Velero snapshots and any tool that redacts `data:` but renders annotations verbatim. This was found live on 2026-08-07: 109 of 122 dockerconfigjson secrets on ever-k8s carried the annotation with a usable GHCR token in it. - `${WORK_SLUG}-pull` duplicated the registry credential. - `${WORK_SLUG}-runtime-env` is worse: it materialises EVERY forwarded repo secret (DATABASE_URL, AUTH_SECRET, COOKIE_SECRET, ...), so it duplicated the app's whole secret set. Both now use `kubectl apply --server-side --force-conflicts`, which records ownership in `.metadata.managedFields` and writes no annotation. `replace --force` also avoids it but deletes and recreates the object, leaving a window where a starting pod finds no pull secret. The namespace, deployment, service and ingress applies are deliberately left as client-side apply - they carry no secret material. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
|
Bugbot is not enabled for your account, so this pull request was not reviewed. Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs. |
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Greptile SummaryThis change switches image-pull and runtime-environment Secret provisioning to server-side apply and updates the README Star History links. Server-side apply prevents new client-side last-applied annotations, but existing fixed-name Secrets are not cleaned up and can retain credential-bearing metadata. T-Rex validation blockedThe focused Kubernetes upgrade-path check could not complete because the disposable Kubernetes v1.31 API server could not select a network address from the runner's default routes. The check must be rerun on a Kubernetes-capable runner or disposable cluster to exercise creation of a legacy Secret followed by the server-side update. Confidence Score: 3/5Not merge-safe until existing legacy Secret annotations are removed during migration. The final findings contain one P1 security issue, which maps to a score of 3 under the required scoring table. The Kubernetes runtime check was attempted but could not reach a usable API server, so it does not alter the score. Files Needing Attention: .github/workflows/deploy_k8s.yaml needs an explicit migration step to remove the legacy last-applied annotation from both fixed-name Secrets.
|
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| --docker-password="$REGISTRY_PASSWORD" \ | ||
| -n "$NAMESPACE" \ | ||
| --dry-run=client -o yaml | kubectl apply -f - | ||
| --dry-run=client -o yaml | kubectl apply --server-side --force-conflicts -f - |
There was a problem hiding this comment.
When these fixed-name Secrets already exist from a client-side apply, server-side apply updates them without removing the legacy kubectl.kubernetes.io/last-applied-configuration annotation, causing registry and application credentials to remain exposed through metadata-rendering dumps, snapshots, and tools. How this was verified: Both Secrets are updated in place, while no workflow command removes the pre-existing annotation.
1 participant
Standard cascade. Carries #1006 (server-side apply for the two Secret-creating steps in
deploy_k8s.yaml, so the credential is no longer duplicated intolast-applied-configurationmetadata) plus one content-neutral docs commit (72dd99eb, Star History link) that was stranded on develop.Content diff between the branches before this PR was 0 files — stage was 191 commits ahead but tree-identical — so this is a clean cascade, not a divergence.
🤖 Generated with Claude Code