neco-admission is a custom admission webhooks for Neco.
It has the following webhooks / controllers.
ArgoCD's Application resource
can specify an AppProject resource
by a spec.project property.
The ability of the Application is restricted by the AppProject it belongs to.
Each application team should specify appropriate spec.projects for
their applications.
To enforce this, ArgoCDApplicationValidator validates Application resources.
See the document for
the configuration of ArgoCDApplicationValidator.
If VAPPLICATION_REPOSITORY_PERMISSIVE=true envvar is set, this does not deny Applications but issues an warning.
Contour's HTTPProxy resource can specify
the Ingress class that should interpret and serve the Ingress.
The annotations
kubernetes.io/ingress.class and projectcontour.io/ingress.class in addition of .spec.ingressClassName field are used
for this specification.
Though the Contour documentation says that all Ingress controllers serve the Ingress if neither the annotations nor the field are not set, this default behavior is dangerous. It may cause unexpected disclosure of services which are intended only for limited network.
The mutating webhook enforces the default ingress class of .spec.ingressClassName=<configured value> for HTTPProxy to prevent such accidents.
The default value can be configured with the --httpproxy-default-class option for neco-admission.
The validating webhook prevents creating HTTPProxy without the annotations nor the field, and prevents updating HTTPProxy to change the annotation values.
The virtual host route set for the HTTPProxy resource has a setting to allow matching requests. The mutating webhook set this filtering policy by the annotation values with a predetermined value.
The validating webhook prevents updating HTTPProxy to change the annotation values. Also, this webhook allows updates to add annotations from an unannotated state.
See the document for
the configuration of HTTPProxyMutator.
This is to protect important resources from accidental deletion by human errors.
Every resource passed to this validation webhook will be denied for DELETE
unless it has this special annotation admission.cybozu.com/i-am-sure-to-delete: <name of the resource>.
However, resources in namespaces that have development: true label can be deleted without the annotation.
This validator enforces that the number of replicas for a Deployment is 0 if the Deployment has a specific annotation. This may be useful to prevent the number of replicas from being rewritten by ArgoCD or operators when the number of replicas is intentionally set to 0.
To enable this validator, annotate a Deployment with admission.cybozu.com/force-replica-count: "0".
Unlike DeleteValidator, this prevents resources from accidental deletion only
if the resource is annotated with admission.cybozu.com/prevent: delete.
However, topolvm-controller can remove PersistentVolumeClaims, even if they are annotated with the above.
PodMutator mutates Pod manifests to specify local ephemeral storage limit to 1GiB and request to 200MiB for each container. The purpose of this mutator is to prevent Pods from overuse of local ephemeral storage.
If VPOD_EPHEMERAL_STORAGE_PERMISSIVE=true envvar is set, local ephemeral storage requests and limits specified in
Pod manifests will not be overwritten.
If you want to use more ephemeral storage than the limit, you can use generic ephemeral volume instead of
local ephemeral storage.
PodValidator validates Pod specifications as follows:
- Check that the container images have a valid prefix such as
ghcr.io/cybozu/.- Valid prefixes are given through
--valid-image-prefixcommand-line flags. - If
VPOD_IMAGE_PERMISSIVE=trueenvvar is set, this does not deny Pods but issues an warning.
- Valid prefixes are given through
GrafanaDashboardValidator validates GrafanaDashboard.
This validating webhook ensures the GrafanaDashboard resource's spec.plugins is empty.
The purpose of this validator is to avoid installing any plugins to production Grafana by tenants.
Docker images are available on ghcr.io