Wire up installation of content using a provided ServiceAccount

[everettraven]

Following #971 and #972, we need to wire up the logic such that a ServiceAccount referenced in a ClusterExtension is used to install/upgrade/uninstall content via the Helm client.

While exact implementation may vary, here are some things to consider during implementation:

• The type implemented in Implement a Go struct for fetching and caching authentication tokens for a ServiceAccount #972 could likely be used to create a client.RestConfigMapper that is used with client.NewActionConfigGetter to configure the helm client created for a given ClusterExtension.
  • You can see where the client.NewActionConfigGetter is configured here:

    operator-controller/cmd/manager/main.go

    Lines 168 to 175 in 2eca31d

    	cfgGetter, err := helmclient.NewActionConfigGetter(mgr.GetConfig(), mgr.GetRESTMapper(),
    	helmclient.StorageNamespaceMapper(installNamespaceMapper),
    	helmclient.ClientNamespaceMapper(installNamespaceMapper),
    	)
    	if err != nil {
    	setupLog.Error(err, "unable to config for creating helm client")
    	os.Exit(1)
    	}

Acceptance Criteria:

• The client.NewActionConfigGetter setup in

  operator-controller/cmd/manager/main.go

  Lines 168 to 175 in 2eca31d

  	cfgGetter, err := helmclient.NewActionConfigGetter(mgr.GetConfig(), mgr.GetRESTMapper(),
  	helmclient.StorageNamespaceMapper(installNamespaceMapper),
  	helmclient.ClientNamespaceMapper(installNamespaceMapper),
  	)
  	if err != nil {
  	setupLog.Error(err, "unable to config for creating helm client")
  	os.Exit(1)
  	}

  is updated to use a client.RestConfigMapper that creates a rest.Config configured with a token from the ServiceAccount referenced in a ClusterExtension
  • The token for this should be retrieved via the implementation in Implement a Go struct for fetching and caching authentication tokens for a ServiceAccount #972
• Updates to the existing unit + e2e tests as necessary for them to continue functioning as expected. It is anticipated that some work will need to be done to configure a ServiceAccount with appropriate permissions to be used during e2e tests.
• Permissions on the operator-controller ServiceAccount should be updated to no longer require write permissions on content to be installed (and clean up any other permissions that are no longer necessary)
• Any changes to the previously implemented interfaces to facilitate the wiring of components successfully are made

[joelanford]

I noticed in #1038 that we use a */*/* ServiceAccount in tests. Can we change those permissions to the minimum necessary ones based on the bundle contents to make sure that future changes we make don't impose more permissions requirements?

[everettraven]

Closing this one as completed as #1038 was merged.

@joelanford Your comment should be addressed via #1074