This change ensures import ordering and aliases is standardized.
Something that is extra important when working with Kuberentes apis that
have "standard" import aliases.
Signed-off-by: Philip Laine <philip.laine@gmail.com>
This change sets some Kubernetes best practices as defaults. Such as
topology spread and pod disruption budget.
It also exposes log level and image settings in the root struct to make
it easier to override commonly configured settings.
Fixes#77Fixes#162
Signed-off-by: Philip Laine <philip.laine@gmail.com>
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.
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>
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>
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.
- 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