The current access restriction feature is no longer functioning reliably due to recent changes in Gardener.
The implementation depends on the seedSelector feature to ensure that new shoots are scheduled on a seed that complies with the required access restriction label.
The access restriction label is defined by the access restriction key in the dashboard configuration.
However, the seedSelector is only applied during shoot creation and cannot be modified afterward. This limitation was recently introduced by Gardener and now prevents the enabling of access restrictions after a shoot has been created (when the seed is already selected). This was changed in Gardener because the seedSelector is only regarded during creation. It makes no sense to set it if a seed has already been selected.
Additionally, with the introduction of control plane migration, it is now possible to change seeds after shoot creation. This can result in a shoot with access restrictions being migrated to a seed that does not meet those requirements.
Access restrictions can only be enabled for shoots that use a region for the cluster workload that has the access restriction label defined in the cloudprofile. However, this is enforced by the Dashboard only. Gardener does not prevent to enable access restrictions for non compliant regions.
Currently, Gardener itself is unaware of the access restriction feature, as it is only implemented in the Gardener Dashboard/Gardenctl.
Proposed Solution
To address these issues, Gardener must become aware of access restrictions to ensure they are enforced when activated for a shoot. A client-side-only solution is no longer sufficient.
Instead of (mis)using the seedSelector, we propose the following:
Introduce a new attribute to the shoot spec or utilize a label controlled by Gardener to enforce access restrictions.
For new shoots:
Gardener should ensure that the selected seed complies with the access restriction requirements (similar to how the seedSelector works).
For existing shoots:
Access restrictions can only be set if the current seed meets the requirements. If not, an error should be returned, instructing the user to migrate the control plane to a compliant seed.
Control plane migration should only be allowed if the new seed meets the access restriction requirements. If not, an error should inform the user that the new seed does not comply with the access restrictions.
Shoot Workload:
Access restrictions can only be set if the shoot region meets the requirements. To check this, a label is added to the region in the cloudprofile (like we already do). Gardener must ensure that the region has the correct label. If not an error should inform the user that the region does not comply with the access restrictions.
The exact changes to the shoot spec are still under discussion. Additionally, we need to clarify how to handle existing shoots and clusters currently in an unsupported state (i.e., those on seeds that do not meet access restriction requirements).
rfranzke
commented
1 month ago
Current Situation
The current access restriction feature is no longer functioning reliably due to recent changes in Gardener.
seedSelectorfeature to ensure that new shoots are scheduled on a seed that complies with the required access restriction label.keyin the dashboard configuration.seedSelectoris only applied during shoot creation and cannot be modified afterward. This limitation was recently introduced by Gardener and now prevents the enabling of access restrictions after a shoot has been created (when the seed is already selected). This was changed in Gardener because theseedSelectoris only regarded during creation. It makes no sense to set it if a seed has already been selected.regionfor the cluster workload that has the access restriction label defined in thecloudprofile. However, this is enforced by the Dashboard only. Gardener does not prevent to enable access restrictions for non compliant regions.Proposed Solution
To address these issues, Gardener must become aware of access restrictions to ensure they are enforced when activated for a shoot. A client-side-only solution is no longer sufficient.
Instead of (mis)using the
seedSelector, we propose the following:Introduce a new attribute to the shoot spec or utilize a label controlled by Gardener to enforce access restrictions.
For new shoots:
seedSelectorworks).For existing shoots:
Shoot Workload:
cloudprofile(like we already do). Gardener must ensure that the region has the correct label. If not an error should inform the user that the region does not comply with the access restrictions.The exact changes to the shoot spec are still under discussion. Additionally, we need to clarify how to handle existing shoots and clusters currently in an unsupported state (i.e., those on seeds that do not meet access restriction requirements).
Tasks