Documentation ¶
Index ¶
Constants ¶
const (
AnchorServingPath = "/validate-hnc-x-k8s-io-v1alpha2-subnamespaceanchors"
)
AnchorServingPath is where the validator will run. Must be kept in sync with the kubebuilder markers below.
const (
ConfigServingPath = "/validate-hnc-x-k8s-io-v1alpha2-hncconfigurations"
)
ConfigServingPath is where the validator will run. Must be kept in sync with the kubebuilder markers below.
const ( // HierarchyServingPath is where the validator will run. Must be kept in sync with the // kubebuilder marker below. HierarchyServingPath = "/validate-hnc-x-k8s-io-v1alpha2-hierarchyconfigurations" )
const (
NamespaceServingPath = "/validate-v1-namespace"
)
NamespaceServingPath is where the validator will run. Must be kept in sync with the kubebuilder markers below.
const (
ObjectsServingPath = "/validate-objects"
)
ObjectsServingPath is where the validator will run. Must be kept in sync with the kubebuilder markers below.
Variables ¶
This section is empty.
Functions ¶
Types ¶
type Anchor ¶
type Anchor struct { Log logr.Logger Forest *forest.Forest // contains filtered or unexported fields }
type HNCConfig ¶
type HNCConfig struct { Log logr.Logger Forest *forest.Forest // contains filtered or unexported fields }
type Hierarchy ¶
type Hierarchy struct { Log logr.Logger Forest *forest.Forest // contains filtered or unexported fields }
func (*Hierarchy) 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`.
type Namespace ¶
type Namespace struct { Log logr.Logger Forest *forest.Forest // contains filtered or unexported fields }