remove ProviderConfig

[displague]

ProviderConfig is conventional in Crossplane providers that require external credentials or differentiating provider configuration.

This provider currently has no need for credentials or configuration outside of what can be provided in a Config resource.

The ProviderConfig resource should therefor be safe to remove from the project.

There are two considerations to make before doing so:

• Does the removal of ProviderConfig impact usability in common provider tooling?
• Is namespace a field that should be defined at the ProviderConfig level? What are the implications of having namespace defined in Config resources, does this allow users to escalate permissions? Are these concerns placated by existing Crossplane best-practices including using Crossplane RBAC and OPA?

[negz]

This could get a little weird in that we do require all managed resources to expose a spec.providerConfigRef, and this assumption is baked into a lot of places. I'm wondering whether it would be better to have a stub/no-op ProviderConfig that didn't actually do anything, as opposed to removing the type altogether. 🤔

[negz]

Would it be feasible for the "provider" in this case to be a reference to the machine the ProviderConfig should be applied to? Similarly to how the "provider" for provider-sql is the SQL instance that should be operated upon, and the "provider" for provider-helm is the Kubernetes cluster that should be deployed to.

I'm guessing this is a little awkward here since cloud-init is a one-shot at-create affair, so you really need to create the Config and reference it from the thing that consumes it (to block its creation), rather than the other way around.

[displague]

The Config resource could be reused between multiple machines, so I would prefer not to scope the target machine at the ProviderConfig or the Config level.

There is one target output resource, the configmaps (or secret). If ProviderConfig defined the target property users would need a new provider config per Config. In this scenario, perhaps the Config resource could give some if it's definition to the ProviderConfig and move parts to a separate ConfigPart resource per part.

Would Namespace scoping for resources, as a property of ProviderConfig be beneficial? Each Config needs to name the namespace for configmaps or secrets they need to create or consume, perhaps this could be (should be?) locked down.