When a pod does not have any annotations the injector will fail. This
change adds a test for the case and also fixes the issue.
Fixes#246
Signed-off-by: Philip Laine <philip.laine@gmail.com>
This change does a few things, none of these are breaking.
It changes the registry from Docker Hub to GHCR, as we dont have the
same rate limiting issues with unauthenticated pulls.
It changes the release process to push the Helm chart as an OCI artifact
removing the need for GH pages.
It renames both the image and chart from kubernetes-operator to
netbird-operator. This name is cleaner and easier for people to
understand in a sea of Helm charts. Funnily enough this is not a
breaking change as the release name is used and not the chart name. So
in place upgrades just work.
Fixes#207
Signed-off-by: Philip Laine <philip.laine@gmail.com>
This change ensures import ordering and aliases is standardized.
Something that is extra important when working with Kuberentes apis that
have "standard" import aliases.
Signed-off-by: Philip Laine <philip.laine@gmail.com>
This change adds a new SidecarProfile resource which allows configuring
client sidecar injection into pods. It replaces the older annotation
based solution. This removes any pod specific configuration from the
setup key and puts it all in this side car configuration.
Fixes#188
Signed-off-by: Philip Laine <philip.laine@gmail.com>
The webhook for the NBSetupKey does a mix of runtime validation and
configuration validation. The validation of secret key ref has been
switched to using CEL rules to achieve the same thing.
The other logic is just being removed as it is goes against common
practice in Kubernetes. We should not block secret deletion if a pod is
using the secret. Existing pods will keep running while new pods will
not be able to be created. This is expected behavior in other tools and
should be dealt with during reconcile.
Checking that secrets exist and other dependency problems should be done
during reconcile and then bubbled up with conditions instead.
Signed-off-by: Philip Laine <philip.laine@gmail.com>
Docs PR: https://github.com/netbirdio/docs/pull/457
Changes:
* Split kubernetes-operator Chart to operator only chart
(kubernetes-operator) and configuration chart (netbird-operator-config)
* Remove delete validation webhooks for non-needed resources
* Allow abandoning Groups when still linked to a resource for over a
minute after deletion
* Fix duplciate Network Resource retrying heavily
* Fix SetupKey creation duplication
* Skip deleting routing peer since deleting network automatically
deletes it anyway
# Fix: NetBird extra-dns-labels not being applied to pods
## Problem
The `netbird.io/extra-dns-labels` annotation was not working when
applied to pods. Despite the webhook detecting the annotation and adding
it to the NetBird container configuration, the extra DNS labels were not
appearing in the NetBird UI or being applied to registered peers.
## Root Cause
The pod webhook had two issues:
1. **Invalid setup key argument**: The webhook was passing
`--setup-key-file /etc/nbkey` to the NetBird client, but this file path
was never created. The setup key was already being passed via the
`NB_SETUP_KEY` environment variable, making the file-based approach
unnecessary and causing confusion in the client startup.
2. **NetBird CLI flag bug**: The webhook was using the
`--extra-dns-labels` command line flag, but NetBird has a known issue
([netbirdio/netbird#4282](https://github.com/netbirdio/netbird/issues/4282))
where this flag is not properly processed. The workaround is to use the
`NB_EXTRA_DNS_LABELS` environment variable instead.
## Solution
- Removed the `--setup-key-file` argument entirely since the setup key
is provided via environment variable
- Removed all command line arguments from the NetBird container
- Added `NB_EXTRA_DNS_LABELS` environment variable when the
`netbird.io/extra-dns-labels` annotation is present
- NetBird client now uses only environment variables for configuration,
which is more reliable and matches the pattern used by the NBRoutingPeer
controller
## Changes
**Before:**
```go
args := []string{
"--setup-key-file", "/etc/nbkey",
"-m", managementURL,
}
// ... add extra-dns-labels to args
```
**After:**
```go
envVars := []corev1.EnvVar{
{Name: "NB_SETUP_KEY", ValueFrom: ...},
{Name: "NB_MANAGEMENT_URL", Value: managementURL},
}
// ... conditionally add NB_EXTRA_DNS_LABELS to envVars
```
## Testing
1. Create a deployment with the `netbird.io/setup-key` and
`netbird.io/extra-dns-labels` annotations:
```yaml
annotations:
netbird.io/setup-key: my-setup-key
netbird.io/extra-dns-labels: "my-label,another-label"
```
2. Verify the environment variable is set:
```bash
kubectl get pod <pod-name> -o jsonpath='{.spec.containers[?(@.name=="netbird")].env[*]}' | jq .
```
3. Check the NetBird UI to confirm the extra DNS labels appear on the
registered peer
4. Verify the NetBird container logs show successful registration
without errors
## References
- NetBird issue: https://github.com/netbirdio/netbird/issues/4282
- Documentation: [Extra DNS
Labels](https://docs.netbird.io/how-to/routing-traffic-to-private-networks#extra-dns-labels)
---
This fix ensures that the `netbird.io/extra-dns-labels` annotation works
as documented and provides a more robust configuration method by using
environment variables consistently across all NetBird deployments in the
operator.
Goreleaser was causing issues when helm chart action created releases
for packaged helm chart, this PR replaces goreleaser with a much simpler
build and push model, and returns packaged helm charts to normal.
- It adds a helm chart that will be hosted in the Github pages URL of this repository
- an admission controller operator
- Basic documentation for installing the operator, configuring CRDs and example pod configuration