Skip to content
This repository has been archived by the owner on Apr 11, 2024. It is now read-only.

feat: deploy mutating webhook #53

Closed
wants to merge 94 commits into from
Closed

Conversation

dkoshkin
Copy link
Collaborator

Wanted to see what everyone thinks, I'll describe the immediate usecase that this helps with.
Related PR #20

There is a handler where a client can set extraAPIServerCertSANs. However, Docker and Nutanix Clusters both already set defaults in KubeadmControlPlaneTemplate.
We would like to move these defaults out of the template and into the openapi schema so that the defaults can be discovered. But for these type of defaults where its also a required value, we want to preserve the defaults even if a user passes additional values. This could be done in the handler, but then the values from extraAPIServerCertSANs in the Cluster would not represent what was used to generate the KubeadmControlPlane.

I'm proposing this webhook to solve the above. The workflow will be:

  • The defaults are set in the openapi schema
  • Users can set additional values in extraAPIServerCertSANs
  • The webhook adds back the defaults

jimmidyson and others added 30 commits March 21, 2024 12:30
Missed when reorganising example kustomizations in previous PR.
- Defines a cluster-level variable for defining one or more users
- Patches bootstrap templates for control plane and worker node pools
  with user configuration
Co-authored-by: Faiq <faiq.raza@nutanix.com>
Signed-off-by: Deepak Muley <deepak.muley@nutanix.com>
Without this, defaults declared in the JSON schema are not included in validation
steps, which can lead to invalid failures, while also not allowing for tests that
target defaults.
Fix typo in lockPassword logic, and add unit test
feat: Add examples for Nutanix provider
Add unit test for empty hashed password
Change Sudo field from pointer to value

The zero value (empty string) is not valid, so the field does not need
to be a pointer.
Explain why we do not validate hashed password input
Explain why we do not validate sudo input
Also deploy infra provider versions that match the API.
CPI is a term unique to the vSphere CCM.
Renaming to the more generic "CCM".
supershal and others added 18 commits April 5, 2024 14:34
* test: unit test for individual patch generator

* test: package level unit test for HTTPProxy

* test: move region and httpproxy patch generator unit test invocation

* fix: linting errors

* test: move all AWS patch unit tests to their own packages (#24)

* test: move instanceprofile tests to its own package

* test: move instancetype unit tests to its own package

* test: move ami unit tests to its own package

* test: move aws network tests to its own package

* test: move controlplaneloadbalancer unit tests to its own package

* test: move aws cni unit tests to its own package

* test: fix linting errors

* test: unit tests for AWS security groups

* test: move customimage unit tests to their own package (#30)

* test:  move all Nutanix patch handler unit tests (#32)

* test: move controlplane endpoint unit tests

* test: move PC endpoint unit tests

* test: nove machinedetails unit tests

* test: move generic patch unit tests to own packages (#31)

* test: move audit policy tests to their own package

* test: move etcd unit tests to their own package

* test: move extra api server cert sans to its own package

* test: move image registry unit tests to its own package

* test: move kubernetes image repository unit tests

* test: move mirror unit tests

* test: move users unit tests

* test: remove gereric unit tests from nutanix meta patch handler

* test: cleaned up meta level unit test suites
* feat: Make containerd restart its own patch

* fix: unit tests for kubeadmconfigtemplate with containerdrestart patch

* fix: add comment for always add containerd patch

* test: move unit test to their own package

---------

Co-authored-by: Shalin Patel <shalin.patel@nutanix.com>
Using a cross-namespace objectRef in the cluster API
can lead to privilege escalation.
A user with RBAC to read Secrets in one namespace can create a cluster,
and copy any Secret from any other namespace to their workload cluster.
* refactor: combine PC host and port into a single url var

This makes it simpler for clients to provide a single input field
and not have to do any parsing to split the hostname and port.
It also allows us to use API validation for bad input.

* fixup! refactor: combine PC host and port into a single url var

* fixup! refactor: combine PC host and port into a single url var

* fixup! refactor: combine PC host and port into a single url var
The existing code created a ClusterResourceSet with the user provided Secret.
However, that won't work unless that Secret has an embedded Secret in it.
* ci: adds tooling to create configmap

* feat: use a configmap to get helmchart info

* fix: precommit issues

* fix: typo in cilium

* fix: remove workspace files

* build: template name for configmap

* refactor: names for helm chart info getter

* refactor: use nutanix-storage name instead of nutnaix-csi

* refactor: move to globaloptions

* fix: adds snapshot to helm config

* fix: comments after review

* fix: adds a warning and removes ebs csi

* fix: typo

* fix: adds missing script file

* fix: precommit
* feat: Add patch to configure containerd metrics
This makes the deployment consistent as well as avoiding issues when providers
are in the middle of a release.
* build: remove nutanix CCM from examples

* build: add scripts to sync Nutanix CCM manifests

* build: add CCM addon var to Nutanix examples

* feat: deploy Nutanix CCM addon

Aligns the method of deploying the CCM with all other addons.

* fixup! build: add scripts to sync Nutanix CCM manifests

* fixup! feat: deploy Nutanix CCM addon

* build: remove unused CRS tooling for Nutanix CCM

The CRS strategy is not supported for the Nutanix CCM,
removing it until we actually need it.
@dlipovetsky
Copy link

Thanks for creating a complete example. I think this could work, but it's rather complex.

I'm not sure the problem deserves a complex solution.

What are the benefits of discoverable "required" defaults? I suppose, if I know what the values are, and pay attention to them, I won't provide redundant or conflicting values.

This could be done in the handler, but then the values from extraAPIServerCertSANs in the Cluster would not represent what was used to generate the KubeadmControlPlane.

Maybe this is not a bad thing? The values are provider-specific, and arguably can/should remain opaque to users.

@jimmidyson
Copy link
Member

jimmidyson commented Apr 11, 2024

For the use case you describe, assuming the defaults are actually required values, then I think the naming of the property extraAPIServerCertSANs already suggests there are a default set to add these extra values to. In this case, I think it is best to add the required values that will always be included to documentation of the field. This would remove all the complexity introduced in the approach taken in this PR.

@dkoshkin
Copy link
Collaborator Author

Thanks for the feedback @dlipovetsky @jimmidyson! I will close this and we can revisit if there is a stronger usecase for this.

@dkoshkin dkoshkin closed this Apr 11, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants