Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

🌱 Use SA from spec when installing bundles #907

Closed
wants to merge 1 commit into from

Conversation

skattoju
Copy link
Contributor

@skattoju skattoju commented Jun 4, 2024

Description

Adds a ServiceAccountName field to the spec and sets up the action client getter to provide an action client that uses a token based on the service account provided in the spec. Related to #737

Reviewer Checklist

  • API Go Documentation
  • Tests: Unit Tests (and E2E Tests, if appropriate)
  • Comprehensive Commit Messages
  • Links to related GitHub Issue(s)

@openshift-ci openshift-ci bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jun 4, 2024
Copy link

netlify bot commented Jun 4, 2024

Deploy Preview for olmv1 ready!

Name Link
🔨 Latest commit 9b1e2e5
🔍 Latest deploy log https://app.netlify.com/sites/olmv1/deploys/6678cffae477b4000824e2e6
😎 Deploy Preview https://deploy-preview-907--olmv1.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

@skattoju skattoju force-pushed the sa_from_spec_poc branch 4 times, most recently from cbc5ef7 to c7e5542 Compare June 10, 2024 18:27
@varshaprasad96
Copy link
Member

/ok-to-test

(not sure if this label is accepted)

@openshift-ci openshift-ci bot added the ok-to-test Indicates a non-member PR verified by an org member that is safe to test. label Jun 10, 2024
InstallNamespace: tc.installNamespace,
PackageName: "package",
InstallNamespace: tc.installNamespace,
ServiceAccountName: tc.serviceAccountName,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test is just for the spec.installNamespace validation. Should we hardcode ServiceAccountName to something we know will be valid?

That would avoid maintainer/contributor confusion. Folks might see that the service account name is varied as part of this test and conclude that the service account name somehow plays into the installNamespace validatation.

We also want to test side-effects from varying service account names.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agreed

}))
if tc.errMsg == "" {
require.NoError(t, err, "unexpected error for installNamespace %q: %w", tc.installNamespace, err)
require.NoError(t, err, "unexpected error for serviceAccountName %q: %w", tc.serviceAccountName, err)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should put the serviceAccount validations into an isolated test.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

makes sense 👍

Comment on lines +7 to +15
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
namespace: default
name: test-clusterrole
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is exactly where I would start (and I know this is still WIP), but before we merge, we should update these rules and potentially create separate sets of rules/serviceaccounts for each test bundle.

That way, we can actually prove to ourselves the what a minimum rule set is for a particular bundle. And we'll want to set a good example and not give service accounts cluster admin.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not related to this work at all: but thinking about it, to make a better UX it would be nice to have some tooling around generating rbac for bundle contents (could be complicated!)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah seems like it will be a lot of trial and error to create the RBAC. Extracting the RBAC from the csv could be a starting point.

cfgGetter, err := helmclient.NewActionConfigGetter(mgr.GetConfig(), mgr.GetRESTMapper(),
helmclient.ClientNamespaceMapper(nsMapper),
helmclient.StorageNamespaceMapper(nsMapper),
helmclient.RestConfigMapper(rcm),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With this setup, we should also remove the */*/* kubebuilder rbac marker in the clusterextension_controller.go file.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we would still need list and watch on all objects right ?
//+kubebuilder:rbac:groups=*,resources=*,verbs=list;watch

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The initial reason for using such a broad RBAC was the uncertainty regarding the objects the bundle would contain. Consequently, the controller was granted admin permissions to monitor and perform CRUD operations on all GVKs.

However, in this scenario, the user (specifically the cluster admin) provides a SA that the controller uses to install contents. It's not necessary for the SA to have admin permissions. Instead, the SA can be granted restricted permissions, limited to only the GVKs present in the bundle. It's expected that the entity providing this SA is aware of the specific permissions needed to install and manage the bundle.

This way we minimise the scope of the SA's access, ensuring it only has the necessary permissions to interact with the relevant GRs.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True for installing the bundles the SA provided in the spec will be used but the controller also establishes watches on the bundle content and this is done with the controller service account so it needs to be able to watch arbitrary objects.

//+kubebuilder:validation:MaxLength:=253
// ServiceAccountName is the name of the ServiceAccount to use to manage the resources in the bundle.
// The service account is expected to exist in the InstallNamespace.
ServiceAccountName string `json:"serviceAccountName"`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Optional Nit: Using https://pkg.go.dev/k8s.io/api/core/v1#LocalObjectReference could be nice here as it is meant for local object references like we are doing here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure what is meant here, is there an example you can point me to ?


type keyLock[K comparable] struct {
locks map[K]*sync.Mutex
mu sync.Mutex
Copy link
Member

@varshaprasad96 varshaprasad96 Jun 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably an implementation nit: Can we also use a sync.RWMutex here so that we allow multiple threads to do concurrent reading. Looks like this is being used to fetch the token so forcing a single lock is unnecessary? (This is based on a quick look at the code, please feel free to correct me if its otherwise)

Comment on lines +7 to +15
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
namespace: default
name: test-clusterrole
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not related to this work at all: but thinking about it, to make a better UX it would be nice to have some tooling around generating rbac for bundle contents (could be complicated!)

@openshift-merge-robot openshift-merge-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jun 14, 2024
@skattoju skattoju force-pushed the sa_from_spec_poc branch 2 times, most recently from ced5993 to b373ac5 Compare June 15, 2024 00:15
@openshift-merge-robot openshift-merge-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jun 15, 2024
@skattoju skattoju force-pushed the sa_from_spec_poc branch 3 times, most recently from e4c62fe to a03522c Compare June 15, 2024 14:26
@openshift-merge-robot openshift-merge-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jun 17, 2024
@openshift-merge-robot openshift-merge-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jun 17, 2024
@skattoju skattoju force-pushed the sa_from_spec_poc branch 2 times, most recently from 857a904 to 8933ba6 Compare June 20, 2024 20:18
@openshift-merge-robot openshift-merge-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jun 24, 2024
@openshift-merge-robot
Copy link

PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

@everettraven
Copy link
Contributor

@skattoju I'm going to close this draft PR since we are going to split the implementation into individual PRs.

Thank you a ton for all the effort you put into this PoC that helped drive the discussion and design process!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. ok-to-test Indicates a non-member PR verified by an org member that is safe to test.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants