Default serviceaccount

[cbarbian-sap]

No description provided.

[cbarbian-sap]

[DISCLAIMER] This PR contains potentially incompatible changes.

• The type reconciler.ReconcilerOptions is changed:

  • The boolean attribute CreateMissingNamespaces is replaced with a new attribute MissingNamespacesPolicy that can have the values Create (default) or DoNotCreate. The default behavior is backwards compatible; only people who explicitly have set the old attribute have to adopt the new notation in the obvious way.
  • Finalizer and field owner used by the reconciler can now explicitly be configured by setting the attributes Finalizer and FieldOwner in the reconciler options. If unset it defaults to the reconciler name passed to reconciler.NewReconciler(), which makes that change backwards compatible.

• The interface component.PolicyConfiguration was enhanced by an additional method GetMissingNamespacesPolicy() reconciler.MissingNamespacesPolicy. People who implemented that interface explicitly have to add this method to their implementation. Most people however probably just include component.PolicySpec into their component's spec type. They don't have to react, but should regenerate their CRD manifest, in order to expose the new field spec.missingNamespacesPolicy which is now contained in component.PolicySpec.

• The type component.ReconcilerOptions is changed in a way similar to reconciler.ReconcilerOptions (that is, the attribute CreateMissingNamespaces is replaced by MissingNamespacesPolicy and new attributes Finalizer and FieldOwner are added). In addition, there is a new option DefaultServiceAccount which allows the name of a service account that can be used during the reconciliation of a component to impersonate the client used to reconcile the dependent objects, as long as the component does not explicitly specify an impersonation or kubeconfig (by implementing the ImpersonationConfiguration or ClientConfiguration interfaces); note that the specified DefaultServiceAccount always refers to the metadata.namespace or the component.

• When a component resource is reconciled, two Kubernetes API clients are constructed:

  • The local client; it always points to the cluster where the component resides. If the component implements impersonation (that is, the component type or its spec implements the ImpersonationConfiguration interface), and an impersonation user or groups are specified by the component resource, then the specified user and groups are used to impersonate the controller's kubeconfig. Otherwise, if a DefaultServiceAccount is defined in the reconciler's options, then that service account (relative to the components metadata.namespace ) is used to impersonate the controller's kubeconfig. Otherwise, the controller's kubeconfig itself is used to build the local client. The local client is passed to generators via their context. For example, the HelmGenerator and KustomizeGenerator provided by component-operator-runtime use the local client to realize the localLookup and mustLocalLookup template functions.
  • The target client; if the component specifies a kubeconfig (by implementing the ClientConfiguration interface), then that kubeconfig is used to build the target client. Otherwise, a local client is used (possibly impersonated), created according the the logic described above. The target client is used to manage dependent objects, and is passed to generators via their context. For example, the HelmGenerator and KustomizeGenerator provided by component-operator-runtime use the target client to realize the lookup and mustLookup template functions.

  This changes the previous impersonation logic a little bit. Other than before, no impersonation happens at all if a kubeconfig is specified (through ClientConfiguration). In addition, relative service accounts returned by GetImpersonationUser() (that is: a user of the form system:serviceaccounts::name, setting an empty namespace), now will be interpreted always relative to the metadata.namespace of the component resource; previously, the namespace specified by a PlacementConfiguration implementation was considered as well; this is no longer the case.

• The clnt parameter of the HelmGenerator and KustomizeGenerator constructors is now ignored (and will be removed in a future release). Instead, these generators always use the local client, constructed as described above.