Clarify that podSelector is optional and defaults to an empty selector,
matching all pods.
Replace “ingress rules” with “rules” to reflect both directions.
Update podSelector descriptions in NetworkPolicy documentation for clarity
The v1alpha3 version is still needed for DeviceTaintRule, but the rest of the
types and most structs became obsolete in v1.32 when we introduced v1beta1 and
bumped the storage version to v1beta1.
Removing them now simplifies adding new features because new fields don't need
to be added to these obsolete types. This could have been done already in 1.33,
but wasn't to minimize disrupting on-going work.
This applies to all group version kinds of Scale. Validation-gen must be enabled for all at the
same time since our testing checks that cross-GV declarative validation to matches.
This adds declarative validation for all all versioned types of Scale
since our testing uses apitesting.VerifyVersionedValidationEquivalence,
will fail if we don't convert them all at the same time.
If someone gains the ability to create static pods, they might try to use that
ability to run code which gets access to the resources associated with some
existing claim which was previously allocated for some other pod. Such an
attempt already fails because the claim status tracks which pods are allowed to
use the claim, the static pod is not in that list, the node is not authorized
to add it, and the kubelet checks that list before starting the pod in
195803cde5/pkg/kubelet/cm/dra/manager.go (L218-L222).
Even if the pod were started, DRA drivers typically manage node-local resources
which can already be accessed via such an attack without involving DRA. DRA
drivers which manage non-node-local resources have to consider access by a
compromised node as part of their threat model.
Nonetheless, it is better to not accept static pods which reference
ResourceClaims or ResourceClaimTemplates in the first place because there
is no valid use case for it.
This is done at different levels for defense in depth:
- configuration validation in the kubelet
- admission checking of node restrictions
- API validation
Co-authored-by: Jordan Liggitt <liggitt@google.com>
Code changes by Jordan, with one small change (resourceClaims -> resourceclaims).
Unit tests by Patrick.
* Always for Immutable selector in Deployment Replicaset Daemonset
With extensions/v1beta1 removed there is no need of a special case
to check for Spec.Selector immutability.
The ValidateImmutableField is now moved into the
Validate[Resource]Update method, tests for v1beta1 are removed and test
for v1 are added.
Validation tests were updated to reflect the changes,
mostly decoupling other fields changes from selectors and creating a
dedicated case to test selector immutability.
* Move validation inside appropriate function
* Fix validation tests
This change modifies the validation logic for ServiceCIDR updates
(`ValidateServiceCIDRUpdate`) to specifically permit upgrading a
single-stack ServiceCIDR (either IPv4 or IPv6) to a dual-stack
configuration.
This reconfiguration path is considered safe because it only involves adding
a new CIDR range without altering the existing primary CIDR. This
ensures that existing Service IP allocations are not disrupted.
Other modifications, such as:
- Downgrading from dual-stack to single-stack
- Reordering CIDRs in a dual-stack configuration
- Changing the primary CIDR during a single-to-dual-stack
reconfiguration
remain disallowed by the validation. These operations carry a higher
risk of breaking existing Services or cluster networking
configurations. Preventing these updates automatically encourages
administrators to perform such changes manually after carefully
assessing the potential impact on their specific cluster environment.
The validation errors and controller logs provide guidance when such
disallowed changes are attempted.
Change-Id: I41dc09dfddb05f277925da2262f8114d6accbd1d
