This change updates the Netbird dependency to the latest version to
enabled #111 to be implemented with future API additions. This change
requires updating the Go version as the upstream dependency requires it.
An interesting aspect that was required was to pin the dex dependency to
v2. It seems like the Netbird go.mod is doing something unexpected with
their version.
Signed-off-by: Philip Laine <philip.laine@gmail.com>
Introduced a new optional boolean field `Privileged` in the
`NBRoutingPeerSpec` to allow deployments to specify if containers should
run in privileged mode. Updated the CRD, Helm templates, and controller
logic to support this feature.
A new function `buildSecurityContext` was added to handle the creation
of the appropriate security context based on the `Privileged` setting.
Tests were updated to cover scenarios where privileged mode is enabled,
disabled, or unspecified. This change allows more granular control over
container security settings, potentially increasing compatibility with
certain workloads that require elevated privileges.
see https://github.com/netbirdio/kubernetes-operator/issues/90
**Note:**
I am not a Go developer and have no experience with this architecture. I
may have overlooked some things.
This change updates Golang CI Lint to the latest version and fixes new
linter errors that came along with the update.
These changes were split out of #112 and are required to update the Go
version.
while fixing #87, noticed a couple lines down that if the containers
spec has more than 1 container, the code probably intends to set
Spec.Containers to a list with a single container, but is instead
setting it to an empty list. The very next lines are trying to access
the 1st element of this empty list, which will result in a panic
Pod labels are being set in line 242, and the`podLabels` variable
already contains the extra `"app.kubernetes.io/name": "netbird-router"`
label, so lines 244-246 are effectively just overwriting any labels that
have been set in the crd.
This is blocking us from using this crd because we need a label
disabling istio injection for the peer to work correctly.
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
Philip LaineandGitHub
JanandGitHub
VladandGitHub
Bethuel MmbagaandGitHub
Tomás MotaandGitHub
M. EssamandGitHub
Christian De LeonandGitHub
athulandM. Essam
Hakan Sariman