Mukul SharmaandClaude Opus 5
76b4ddd2de
toolshed provisions a per-app Redis ACL user, scoped to its own key prefix, on request (internal/dbprovision.EnsureRedisUser). Nothing in this cluster ran Redis — Harbor's internal one is Harbor's and is not ACL configured — so there was nowhere for that to point. Hand-written rather than vendoring Bitnami's, same reasoning as the sibling postgresql chart: Broadcom has been retiring and freezing images behind that repo (infra issue #4, where it broke Contour twice), and Redis publishes no official chart either. The authentication design is the part worth reading before changing anything. Redis is started with an ACL file and NO requirepass, and that distinction is a security property rather than a style choice: - toolshed persists provisioned users with ACL SAVE, which requires an aclfile. Without it every provisioned user is lost on the next restart. - But ACL SAVE also serialises the default user. With requirepass, the saved entry comes back as `user default on nopass ~* &* +@all`, and after the next restart the ACL file wins — leaving Redis open to UNAUTHENTICATED access with full permissions. Verified directly: with requirepass, the restarted server answered an unauthenticated PING with PONG and served a key. So the default user is defined in the ACL file instead, seeded once by an init container that deliberately never overwrites an existing file — overwriting would delete every user toolshed had provisioned into it, reintroducing the same lockout from the other end. The documented consequence is that rotating the admin password in Vault does not propagate on its own; that needs ACL SETUSER default + ACL SAVE against the running server. Sized for a node at its ceiling: 32Mi requested, 96Mi limit, maxmemory 48mb. The limit sits above maxmemory on purpose, so Redis reaches its own eviction policy rather than being OOM-killed, which would lose the whole instance instead of the coldest keys. Snapshotting is off — what must survive a restart is the ACL file, which ACL SAVE writes independently of RDB, and cached values are by definition reconstructible. allkeys-lru because this backs a connection kind called "cache" and eviction under pressure is that contract; values.yaml says plainly that an app using Redis as its only copy of something wants noeviction instead. Verified: helm template, then a real deploy to a k3d cluster — provisioned users through toolshed's own code, deleted the pod, and confirmed all five came back with their key patterns intact, the init container declined to overwrite, unauthenticated access got NOAUTH, and a user writing outside its prefix got NOPERM. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wajog7nELA3i8JWTjxYGHF
devops-infra-helm-charts
This branch (main) is part of the restructuring process for the gcp-devops-admin repository, aimed at organizing helmcharts of all infrastructure tools and their corresponding value files. The purpose of this repository is to centralize and manage these resources efficiently.
Directory Structure
helm-templates
This directory is intended for caching or forking helm charts locally. If there's a need to modify or customize any helm chart, it can be done here. Otherwise, the charts will be used directly from the provider.
helm-overrides
The helm-overrides folder stores custom values files for helm charts. These files can be used to override the default values provided by the helm charts, whether they are forked or used directly from the provider.
cluster_name
Each tool within the repository may have different values based on the specific clusters. This directory is used to manage configurations and values tailored to different clusters.
manifests
The manifests directory contains manifest files that need to be applied only once. Examples include service-to-service configurations, storage classes, and any other manifest-related files necessary for the operation of the infrastructure tools.
Additional Notes
Please ensure that all changes made to this branch align with the restructuring objectives and follow the best practices for managing helm charts and infrastructure-related configurations.
For any questions or concerns, please reach out to the designated repository maintainers.