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>
Group names are unique so we can safely use the name as a reference
method to groups. This makes assigning resources created in the cluster
to groups that already exist a lot easier.
Using kubectl to manage configuration is not a sustainable solution and
not something that we want to promote users to do. This removes the
creation of the image and use of the image in the Helm charts.
This change adds two new resources, NetworkRouter and NetworkResource,
which enable clusters to expose Kubernetes services to Netbird.
The NetworkRouter is responsible for creating the network, group, setup
key and routing peer all of which are unique to the isntance. Along with
the deployment of the client in the cluster.
The NetworkResource exposes a service by linking to the specific router
it wants to expose to. This makes coupling between the resource and
network easy to understand.
Routers also set a DNS zone which is used to give names to resources
based on the name and namespace of the service being exposed.
Part of #172
Signed-off-by: Philip Laine <philip.laine@gmail.com>
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)
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.