Propagating labels through internal resources managed by ARC can cause issues when ARC is used in combination with other tools, such as ArgoCD. This change introduces new flag on the controller that accepts the list of label prefixes that shouldn't be propagated to internal resources.
The reason we choose to opt out of labels instead of opt in to the label propagation behavior is due to several reasons:
If cluster policies are configured to ensure every resource has a particular label, then propagating labels is a requirement
If you are applying specific labels in order to easily manage resources, you should be able to inspect sub-resources based on that label.
If you have cluster policies to propagate labels, and you want to use systems similar to Argo, that use resource tracking and act on it based on label, you should have a way to opt out of propagating specific labels.
Turning on/off label propagation would not solve the issue if you have cluster policies and you are managing your cluster with Argo. So this more granular approach ensures both scenarios are covered.
The resource builder component is instantiated with the ruleset, and will ignore labels that match the prefix configured.
Propagating labels through internal resources managed by ARC can cause issues when ARC is used in combination with other tools, such as ArgoCD. This change introduces new flag on the controller that accepts the list of label prefixes that shouldn't be propagated to internal resources.
The reason we choose to opt out of labels instead of opt in to the label propagation behavior is due to several reasons:
Turning on/off label propagation would not solve the issue if you have cluster policies and you are managing your cluster with Argo. So this more granular approach ensures both scenarios are covered.
The
resource buildercomponent is instantiated with the ruleset, and will ignore labels that match the prefix configured.Fixes #3533