mirror of
https://github.com/seaweedfs/seaweedfs.git
synced 2026-09-08 15:41:15 +02:00
master
3
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
0720955ea7 |
helm: pass extraEnvironmentVars and security.toml to the bucket-creation hook (#10477)
* helm: give the bucket hook the credentials weed shell needs The post-install bucket hook pipes s3.configure into `weed shell`. Since #9442 the filer only serves its IAM gRPC service to callers presenting an admin-signed JWT, and since #9536 `weed shell` mints that token itself - but only if it can find the filer signing key. The hook job sees neither a security.toml nor the WEED_* environment overrides: its env list is hardcoded, and it is the only workload in the chart without a security.toml mount. So with jwtSigning.filerWrite=true the hook logs error: failed to get user anonymous: rpc error: code = Unauthenticated desc = missing authorization metadata and `weed shell` exits 0 regardless, which leaves the Job green while anonymousRead is never applied. Render the merged extraEnvironmentVars into the job's env - keeping non-string values as valueFrom, so keys held in a Secret stay a reference - and mount security.toml the way every other workload does. The hardcoded WEED_CLUSTER_* entries go away because those values are part of the global extraEnvironmentVars defaults and would otherwise render twice. Signed-off-by: Sebastian Preisner <preisner@puzzle-itc.de> Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * helm ci: report a missing bucket hook Job instead of crashing Signed-off-by: Sebastian Preisner <preisner@puzzle-itc.de> Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * helm ci: assert where the bucket hook mounts security.toml A mount under the wrong path leaves weed shell without the key just as surely as no mount at all, so check the target, not only the name. Signed-off-by: Sebastian Preisner <preisner@puzzle-itc.de> Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * helm: keep the bucket hook's cluster endpoints chart-computed Dropping the hardcoded WEED_CLUSTER_* left the readiness waits dereferencing $WEED_CLUSTER_SW_*, which exist only while the values keep the default alias. Rename the cluster, or clear extraEnvironmentVars, and the hook polls "http://" for five minutes and then fails the release. Derive the env names from the alias and render the addresses from the chart, as all-in-one already does. * helm ci: assert the bucket hook follows a renamed cluster alias Renames the cluster and drops the default addresses, then checks that every env name the readiness waits dereference is set, and that the address is the chart's rather than the one left in the values. * helm ci: check the hook's endpoints and security.toml source The bucket hook tests took two shortcuts a wrong render slips through. The alias test only rejected the stale master address the values kept, so any other wrong address passed and the filer address was never compared at all. And the security.toml test matched the volume by name, which a same-named emptyDir or a foreign ConfigMap satisfies while `weed shell` still has no signing key. Compare both cluster addresses against the Services the chart renders, in the default and the renamed-alias case, and assert the volume is backed by the chart's security-config ConfigMap. Checked by pointing the volume at another ConfigMap and the filer env at a wrong but non-empty address: both now fail, both passed before. Signed-off-by: Sebastian Preisner <preisner@puzzle-itc.de> Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Sebastian Preisner <preisner@puzzle-itc.de> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Chris Lu <chris.lu@gmail.com> |
||
|
|
09da5f634f |
helm: optional NetworkPolicy per component (#10479)
* helm: optional NetworkPolicy per component In a namespace with a default-deny policy the chart cannot be installed: the components never reach each other, and the post-install bucket hook waits on the master and filer until it gives up. networkPolicy.enabled renders one policy per component, selecting its pods by the standard app.kubernetes.io labels and admitting the other pods of the release on the ports that component listens on. The port lists come from the same values as the containerPorts, and CI asserts the two agree. Restricting egress is a second opt-in with extraEgress for the filer store and notification sinks, which the chart cannot know about. Closes #10421 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * helm: say "changed" instead of "retuned" in the policy comments codespell reads "retuned" as a misspelling of "returned" and fails the spelling job. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * helm: refuse empty port and DNS peer lists instead of widening In a NetworkPolicy an empty ports list means every port and a missing peer selector means every pod, so `kubeApiServer.ports: []` silently opened the API server CIDRs on all ports, and nulling a DNS selector rendered `podSelector: null`, which is every pod in kube-system. Both now fail the render, and the DNS rule emits only the selectors that are set. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * helm: gate the bucket hook Job and its policy on one helper Both were deriving the same condition from the same values, kept in step by a comment. seaweedfs.bucketHookEnabled makes it one definition, so adding an S3 mode cannot leave the Job running without its policy - which under default-deny means the hook hangs. CI pins the pairing across the eleven modes that decide it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * helm: say that an egress default-deny needs both toggles networkPolicy.enabled on its own only covers a default-deny that restricts ingress. Where Egress is in its policyTypes as well, which is the usual baseline, the components still cannot resolve DNS and egress.enabled is required too. Both values and the README said the first half of that. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * helm: quote the label values the policies emit The same int-coercion the hook templates were fixed for, in the file this PR adds: unquoted, a release named 123 renders app.kubernetes.io/instance as a YAML integer in the metadata, the podSelector and both peer selectors, and the API server rejects the object - a policy that silently never applies. CI now renders the chart as release "123" and fails if any policy label comes out as a non-string. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * helm: gate the resize hook policy on the same lookup as its Job The policy rendered whenever the hook was enabled, which is the default, so every release carrying networkPolicy got one - as a pre-install hook that Helm never collects, left in the namespace after uninstall. It also made egress.kubeApiServer.cidrs mandatory for every release, since the policy claims the API server, for a Job that only runs on an upgrade that grows a PVC. Move the command computation the Job is gated on into a helper and read it from both. * helm: drop the API server rule from the admin policy No seaweedfs binary talks to the Kubernetes API - there is no client-go in go.mod - so the rule granted admin an egress path it never uses, and forced anyone running admin with egress on to name an API server address for it. The pod-RW ClusterRole the comment was reasoning from is a leftover from a migration and is not read by any component. * helm: reject a networkPolicy.components key that names no component The component names are not guessable - objectstorage-provisioner, seaweedfs-all-in-one, volume-<name> - and a typo silently dropped the rules it was carrying. Check against every component the chart can produce, not the enabled ones, so a values file shared across releases can still hold overrides for a component this one leaves off. * helm: name the all-in-one policy after the workload componentName prefixes the release fullname onto the suffix it is given, and the component label already starts with seaweedfs-, so the policy came out as <release>-seaweedfs-seaweedfs-all-in-one. * helm ci: assert the denied probe failed rather than that it did not succeed kubectl run's "pod/x created" was captured alongside the pod log, so an empty log would still not match exit=0 and the denial would pass without anything having been tested. * helm: document what turning the network policies on costs Three things the values did not say: a Prometheus outside the release stops scraping and nothing reports it, the resize hook's policy is a hook resource that uninstall leaves behind, and the DNS selectors are wrong on OpenShift. * helm: spell out the managed distributions codespell reads as a typo codespell has AKS in its dictionary as a misspelling of ASK, so the DNS selector note failed the spelling job. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * helm ci: read the probe verdict from the marker line, not the whole log The default-deny step decides both probes from the pod log, but kubectl logs returns stderr as well, and busybox wget reports "download timed out" there even under -q. The denied probe therefore produced two lines beginning with wget:, which matches neither exit=0 nor exit=*, so a correct denial landed in the arm meant for a probe that produced no result at all and failed the job. The earlier form hid this behind a catch-all that treated anything without exit=0 as a denial; tightening that assertion made the stray line fatal without narrowing the input it reads. Pick the marker line out instead. The trailing || true is required: the step runs under bash -e, so a grep that matches nothing would abort it rather than reach the arm that reports an empty result, which is the case that assertion exists to catch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Sebastian Preisner <preisner@puzzle-itc.de> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Chris Lu <chris.lu@gmail.com> |
||
|
|
a1a3ac5b82 |
helm: label the hook Job pods so selectors can reach them (#10478)
* helm: label the hook Job pods so selectors can reach them The bucket hook pod carries only managed-by/instance and the volume resize hook pod carries no labels at all, so nothing keyed on the standard app.kubernetes.io set can address either of them. Give both the same name/chart/managed-by/instance/component labels the other workloads use, with the component naming each hook. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * helm ci: assert the whole label set on the Job and its pod The block checked three keys and only looked at the pod's component, so a missing chart/managed-by label, a wrong component on the Job, or a Job and pod that disagree would all have passed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * helm ci: compare the hook's release labels against a real workload Presence alone let a wrong value through. The name/instance/chart values now have to match a workload that already renders them, which also keeps the chart version out of the test. managed-by stays a presence check: the chart puts it on workload metadata but not on pod templates. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * helm: quote the resize hook's managed-by and instance labels Matches the bucket hook, and keeps a numeric release name a string instead of an int the API server rejects. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Sebastian Preisner <preisner@puzzle-itc.de> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |