This change adds a ready condition. It also sets a standard for status
fields and documentation. It makes use of helper functions from FluxCD
to better manage patching of finalizers and status.
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 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 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>
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>
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.
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.
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
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
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
Nicolas FratiandGitHub
David FischerandGitHub
GideonandGitHub
JanandGitHub
Bethuel MmbagaandGitHub
M. EssamandGitHub
athulandM. Essam
rarroubaandM. Essam
Maycon SantosandGitHub
David FryandGitHub
David FryandM. Essam
Mykola DzhamandM. Essam