This makes testing of the operator a lot simpler by enabling a quick way
to implement the crud endpoints for all the resources used.
Signed-off-by: Philip Laine <philip.laine@gmail.com>
This change implements a new group resource.
It also sets the standard for a resource reference will be done through
out the controller. A resource reference can either be done by ID or as
a local named reference to the actual resource. This allows end users to
chose if they want to manage things completely in the cluster or not.
Part of #172
Signed-off-by: Philip Laine <philip.laine@gmail.com>
This change implements a new resource called SetupKey that manages the
lifecycle of setup keys and stores them in secrets.
A major change here is that we are also switching to using SSA for
resource management.
Part of #172
Signed-off-by: Philip Laine <philip.laine@gmail.com>
This refactors the deployment creation for the routing peer to use the
create or update method. Keeping this a lot cleaner. It also changes to
set controller reference using the util method.
This change adds support for TCPRoutes when using a private gateway
class. This is similar to annotating services today. It also moves the
gateway classes to the Helm chart as it makes things a lot simpler for
the end user as they no longer have to define them.
Signed-off-by: Philip Laine <philip.laine@gmail.com>
This just changes how a routing peer is referenced. In my head this
model makes more sense, especially as we need at least one listener
right now.
Signed-off-by: Philip Laine <philip.laine@gmail.com>
This changes the behavior of the Netbird resource so that they can be
shared between routes rather than having one unique created per route.
This is important as we may want to have different route types pointing
to the same service.
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>
This change adds support for the new proxy service to the operator
through Gateway API. This change attempts to standardize concepts around
the Gateway API to allow for compatibility with other projects.
Fixes#111Fixes#44
Signed-off-by: Philip Laine <philip.laine@gmail.com>
Making the runtime namespace configurable makes it possible to run
locally outside of the cluster. This is useful for quick development
testing.
Signed-off-by: Philip Laine <philip.laine@gmail.com>
HTTP2 was disabled to mitigate security risks from CVE-2023-44487 and
CVE-2023-39325 which have long since been fixed in Go. Removing the
option that was false by default enables http2 and also reduces some
confusion about why it is an option in the first place.
Signed-off-by: Philip Laine <philip.laine@gmail.com>
Manifest generation has drifted from what is committed to the repo. This
change adds checks for both manifests and code generation to make sure
it is up to date in every PR.
Bumps [github.com/onsi/ginkgo/v2](https://github.com/onsi/ginkgo) from
2.21.0 to 2.28.1.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/onsi/ginkgo/releases">github.com/onsi/ginkgo/v2's
releases</a>.</em></p>
<blockquote>
<h2>v2.28.1</h2>
<h2>2.28.1</h2>
<p>Update all dependencies. This auto-updated the required version of Go
to 1.24, consistent with the fact that Go 1.23 has been out of support
for almost six months.</p>
<h2>v2.28.0</h2>
<h2>2.28.0</h2>
<p>Ginkgo's SemVer filter now supports filtering multiple components by
SemVer version:</p>
<pre lang="go"><code>It("should work in a specific version range
(1.0.0, 2.0.0) and third-party dependency redis in [8.0.0, ~)",
SemVerConstraint(">= 3.2.0"),
ComponentSemVerConstraint("redis", ">= 8.0.0")
func() {
// This test will only run when version is between 1.0.0 (exclusive) and
2.0.0 (exclusive) and redis version is >= 8.0.0
})
</code></pre>
<p>can be filtered in or out with an invocation like:</p>
<pre lang="bash"><code>ginkgo --sem-ver-filter="2.1.1,
redis=8.2.0"
</code></pre>
<p>Huge thanks to <a
href="https://github.com/Icarus9913"><code>@Icarus9913</code></a> for
working on this!</p>
<h2>v2.27.5</h2>
<h2>2.27.5</h2>
<h3>Fixes</h3>
<p>Don't make a new formatter for each GinkgoT(); that's just silly and
uses precious memory</p>
<h2>v2.27.4</h2>
<h2>2.27.4</h2>
<h3>Fixes</h3>
<ul>
<li>CurrentTreeConstructionNodeReport: fix for nested container nodes
[59bc751]</li>
</ul>
<h2>v2.27.3</h2>
<h2>2.27.3</h2>
<h3>Fixes</h3>
<p>report exit result in case of failure [1c9f356]
fix data race [ece19c8]</p>
<h2>v2.27.2</h2>
<h2>2.27.2</h2>
<h3>Fixes</h3>
<ul>
<li>inline automaxprocs to simplify dependencies; this will be removed
when Go 1.26 comes out [a69113a]</li>
</ul>
<h3>Maintenance</h3>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/onsi/ginkgo/blob/master/CHANGELOG.md">github.com/onsi/ginkgo/v2's
changelog</a>.</em></p>
<blockquote>
<h2>2.28.1</h2>
<p>Update all dependencies. This auto-updated the required version of Go
to 1.24, consistent with the fact that Go 1.23 has been out of support
for almost six months.</p>
<h2>2.28.0</h2>
<p>Ginkgo's SemVer filter now supports filtering multiple components by
SemVer version:</p>
<pre lang="go"><code>It("should work in a specific version range
(1.0.0, 2.0.0) and third-party dependency redis in [8.0.0, ~)",
SemVerConstraint(">= 3.2.0"),
ComponentSemVerConstraint("redis", ">= 8.0.0")
func() {
// This test will only run when version is between 1.0.0 (exclusive) and
2.0.0 (exclusive) and redis version is >= 8.0.0
})
</code></pre>
<p>can be filtered in or out with an invocation like:</p>
<pre lang="bash"><code>ginkgo --sem-ver-filter="2.1.1,
redis=8.2.0"
</code></pre>
<p>Huge thanks to <a
href="https://github.com/Icarus9913"><code>@Icarus9913</code></a> for
working on this!</p>
<h2>2.27.5</h2>
<h3>Fixes</h3>
<p>Don't make a new formatter for each GinkgoT(); that's just silly and
uses precious memory</p>
<h2>2.27.4</h2>
<h3>Fixes</h3>
<ul>
<li>CurrentTreeConstructionNodeReport: fix for nested container nodes
[59bc751]</li>
</ul>
<h2>2.27.3</h2>
<h3>Fixes</h3>
<p>report exit result in case of failure [1c9f356]
fix data race [ece19c8]</p>
<h2>2.27.2</h2>
<h3>Fixes</h3>
<ul>
<li>inline automaxprocs to simplify dependencies; this will be removed
when Go 1.26 comes out [a69113a]</li>
</ul>
<h3>Maintenance</h3>
<ul>
<li>Fix syntax errors and typo [a99c6e0]</li>
<li>Fix paragraph position error [f993df5]</li>
</ul>
<h2>2.27.1</h2>
<h3>Fixes</h3>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://github.com/onsi/ginkgo/commit/5d1d628ac86668c8f944c8c491c3d1ab86b3bed4"><code>5d1d628</code></a>
v2.28.1</li>
<li><a
href="https://github.com/onsi/ginkgo/commit/676f985d26d9b5d02f73086760883f7086bb5386"><code>676f985</code></a>
update test mu language</li>
<li><a
href="https://github.com/onsi/ginkgo/commit/8032100d256f25df9be61f2623fc244c9ea0cafb"><code>8032100</code></a>
appease go vet</li>
<li><a
href="https://github.com/onsi/ginkgo/commit/41ca8077223910d4d20e099204a8520057ab8b82"><code>41ca807</code></a>
bump dependencies</li>
<li><a
href="https://github.com/onsi/ginkgo/commit/2b2305b02aad8f5316b0bfcaabe5b9789d988db6"><code>2b2305b</code></a>
v2.28.0</li>
<li><a
href="https://github.com/onsi/ginkgo/commit/71d2d89adc9387d4f4fc579438b5631d9180d687"><code>71d2d89</code></a>
feat: support component semantic version filtering</li>
<li><a
href="https://github.com/onsi/ginkgo/commit/8cbbcb4709d306183de94f0699dd92affeb6f5b0"><code>8cbbcb4</code></a>
Fix doclink for ginkgo run</li>
<li><a
href="https://github.com/onsi/ginkgo/commit/a92830749ce9b1271ffac08abce793ae937fe9d4"><code>a928307</code></a>
v2.27.5</li>
<li><a
href="https://github.com/onsi/ginkgo/commit/0d0e96db305b01ce8642008053b857363ca87ecb"><code>0d0e96d</code></a>
don't make a new formatter for each GinkgoT(); that's just silly and
uses pre...</li>
<li><a
href="https://github.com/onsi/ginkgo/commit/867ce95f5142649695406f751f883c99ea45c0d5"><code>867ce95</code></a>
v2.27.4</li>
<li>Additional commits viewable in <a
href="https://github.com/onsi/ginkgo/compare/v2.21.0...v2.28.1">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
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.
Philip LaineandGitHub
Nicolas FratiandGitHub
David FischerandGitHub
GideonandGitHub
Tamer FahmyandGitHub
JanandGitHub
Bethuel MmbagaandGitHub
VladandGitHub
Tomás MotaandGitHub
Maycon SantosandGitHub
M. EssamandGitHub
Christian De LeonandGitHub