The chart defaults the validating webhook to port 10250, which the
kubelet also serves on. When a connection to the webhook Service
resolves to a node IP rather than a Pod IP it reaches the kubelet,
which completes the TLS handshake with its node serving certificate,
and the apiserver rejects the call with an x509 error naming the node
instead of the webhook Service. The certificate is valid, just the
wrong server's, so the failure reads as a PKI fault and hides the
misroute behind it. Moving the listener to a port nothing else answers
on turns the same misroute into a connection refusal, which names the
real problem. This does not prevent the misroute.
9443, the controller-runtime default this chart would otherwise take,
is disqualified: the etcd kube-rbac-proxy binds it on host-network, so
it would swap one wrong certificate for another. Nothing in the tree
binds 10260 in a node network namespace. It remains
CloudControllerManagerWebhookPort in k8s.io/cloud-provider, so a
host-network cloud-controller-manager added later has to keep clear of
it.
Point the Service at the "webhook" container-port name so the move is
safe. Upstream renders targetPort from webhook.port as a number, which
every endpoint shares regardless of what its Pod listens on, so
changing the port alone would aim the Service at a port the outgoing
Pod does not serve until the replacement passes readiness. That window
rejects admission for externalsecrets, secretstores and
clustersecretstores, and breaks CRD conversion, which routes through
the same Service. No values-only setting closes it; a named targetPort
resolves per-Pod and does.
Add unit tests pinning the listener flag, the containerPort and the
named targetPort. This chart's values.schema.json allows unknown keys,
so a renamed upstream value would be silently ignored and the port
would revert to 10250 with nothing else noticing.
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Move common-envs.mk and package.mk from scripts/ to hack/ directory.
Update all Makefile includes to use new paths. Remove unused
issue-flux-certificates.sh script.
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: Andrei Kvapil <kvapss@gmail.com>
This pull request adds the external-secrets-operator to our main
bundles. By integrating the external-secrets-operator, we enable
seamless connectivity to external hosted secret management services such
as HashiCorp Vault, 1Password, AWS Secrets Manager, and more.
Benefits:
Unified Secret Management: Allows the application to securely fetch
secrets from external providers without hardcoding them into
configurations.
Flexibility: Supports multiple external secret stores, giving users the
freedom to choose their preferred secret management solution.
Enhanced Security: Reduces the risk of exposing sensitive information by
leveraging established secret management platforms.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Introduced the `external-secrets-operator` for managing external
secrets in Kubernetes.
- Added a Helm chart for the `external-secrets` application, including
configuration options and dependencies.
- Implemented a certificate controller within the
external-secrets-operator.
- **Documentation**
- Added README.md with installation instructions and configuration
options for the External Secrets Operator.
- Included success message and setup instructions in NOTES.txt for the
external-secrets deployment.
- **Chores**
- Created .helmignore to streamline Helm packaging by excluding
unnecessary files.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Signed-off-by: Andrei Kvapil <kvapss@gmail.com>
Co-authored-by: Andrei Kvapil <kvapss@gmail.com>
Aleksei Sviridkin