This change does some cleanup of the actions workflows to makes them
faster to run and easier to debug. It pins all of the actions workflows
to specific commit hashes. Dependabot will be enabled in a separate PR
to manage updates.
Signed-off-by: Philip Laine <philip.laine@gmail.com>
This change fixes flaky e2e tests with two changes. The first is that
the manager container is checked for ready condition rather than
running. The second is that the webhook server has been registered as
part of the health check to verify it is running before reporting ready
state.
Signed-off-by: Philip Laine <philip.laine@gmail.com>
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>
Minor adjustment to the NBPolicy template to make ports and protocols
render as lists instead of strings.
Previously a values file like
```yaml
policies:
demo-policy:
name: "Demo Policy"
sourceGroups:
- demogroup
- demogroup2
ports:
- 443
- 80
protocols:
- tcp
- udp
```
would result in a rendered manifest like
```yaml
spec:
bidirectional: false
name: Demo Policy
ports:
- 80 443
protocols:
- tcp udp
sourceGroups:
- demogroup
- demogroup2
```
(.spec.ports[0]: expected numeric (int or float), got string)
## Problem
The `netbird-operator-config` ClusterRole only grants `get` on
`nbroutingpeers`, but the `kubernetes-service-expose` job uses a
reflector/informer internally which requires both `list` and `watch` to
establish a watch stream. This results in the following error at
runtime:
```
E0218 16:28:42.344838 1 reflector.go:204] "Failed to watch" err="failed to list *unstructured.Unstructured: nbroutingpeers.netbird.io \"router\" is forbidden: User \"system:serviceaccount:netbird:netbird-operator-config\" cannot list resource \"nbroutingpeers\" in API group \"netbird.io\" in the namespace \"netbird\""
```
I noticed this error when I enabled the `kubernetesAPI.enabled` flag in
the netbird-oberator-config helm chart.
## Fix
Add `list` and `watch` verbs to the `nbroutingpeers` rule in the
ClusterRole, consistent with how other `netbird.io` resources are
already granted in the same role.
## Related
Similar issue was reported previously in #24 for a different service
account.
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.
The reason for this PR is that currently if the secret doesn’t have the
key NB_API_KEY yet at deployment time, the deployment will still run and
pull in an env list that doesn’t include NB_API_KEY since the envFrom
will just pull any and all keys it finds in the secret and makes env
vars out of them. then at a later point, once the NB_API_KEY key is
populated in the secret, one has to bounce the pod to get the key to be
picked up.
if you use the env: valueFrom syntax using a named key, if that named
key doesn’t exist, the deployment should give an error and retry until
the secret key is available
Operator checks for existence of NetBird API key to create controllers
for Service, NBResource, NBPolicy ...etc, while the Helm chart checks
for Values.ingress.enabled, this causes crashes if NetBird API Key is
provided but ingress.enabled is set to `false`.
This fixes this discrepancy by checking NetBird API key in Helm instead
of ingress enabled value.
resolves#13
Philip LaineandGitHub
David FischerandGitHub
GideonandGitHub
Tamer FahmyandGitHub
JanandGitHub
Bethuel MmbagaandGitHub
VladandGitHub
Tomás MotaandGitHub
Maycon SantosandGitHub
M. EssamandGitHub
Christian De LeonandGitHub
athulandM. Essam
rarroubaandM. Essam
David FryandGitHub
Frederic RoggonandGitHub
David FryandM. Essam
Mykola DzhamandM. Essam