Documentation
¶
Index ¶
Constants ¶
const ( // ServingPath is where the validator will run. Must be kept in sync with the // kubebuilder marker below. ServingPath = "/validate-hnc-x-k8s-io-v1alpha2-hierarchyconfigurations" )
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
type AnchorReconcilerType ¶
type HNCConfigReconcilerType ¶
type HNCConfigReconcilerType interface {
Enqueue(msg string)
}
type Reconciler ¶
type Reconciler struct {
client.Client
Log logr.Logger
// Forest is the in-memory data structure that is shared with all other reconcilers.
// Reconciler is responsible for keeping it up-to-date, but the other reconcilers
// use it to determine how to propagate objects.
Forest *forest.Forest
// contains filtered or unexported fields
}
Reconciler is responsible for determining the forest structure from the Hierarchy CRs, as well as ensuring all objects in the forest are propagated correctly when the hierarchy changes. It can also set the status of the Hierarchy CRs, as well as (in rare cases) override part of its spec (i.e., if a parent namespace no longer exists).
func (*Reconciler) Reconcile ¶
Reconcile sets up some basic variables and then calls the business logic.
func (*Reconciler) SetupWithManager ¶
func (r *Reconciler) SetupWithManager(mgr ctrl.Manager, maxReconciles int) error
type Validator ¶
type Validator struct {
Log logr.Logger
Forest *forest.Forest
// contains filtered or unexported fields
}
func (*Validator) Handle ¶
Handle implements the validation webhook.
During updates, the validator currently ignores the existing state of the object (`oldObject`). The reason is that most of the checks being performed are on the state of the entire forest, not on any one object, so having the _very_ latest information on _one_ object doesn't really help us. That is, we're basically forced to assume that the in-memory forest is fully up-to-date.
Obviously, there are times when this assumption will be incorrect - for example, when the HNC is just starting up, or perhaps if there have been a lot of changes made very quickly that the reconciler has't caught up with yet. In such cases, this validator can produce both false negatives (legal changes are incorrectly rejected) or false positives (illegal changes are mistakenly allowed). False negatives can easily be retried and so are not a significant problem, since (by definition) we expect the problem to be transient.
False positives are a more serious concern, and fall into two categories: structural failures, and authz failures. Regarding structural failures, the reconciler has been designed to assume that the validator is _never_ running, and any illegal configuration that makes it into K8s will simply be reported via HierarchyConfiguration.Status.Conditions. It's the admins' responsibilities to monitor these conditions and ensure that, transient exceptions aside, all namespaces are condition-free. Note that even if the validator is working perfectly, it's still possible to introduce structural failures, as described in the user docs.
Authz false positives are prevented as described by the comments to `getServerChecks`.
Source Files