-
Notifications
You must be signed in to change notification settings - Fork 48
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
Conversation
✅ Deploy Preview for olmv1 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
cbc5ef7
to
c7e5542
Compare
/ok-to-test (not sure if this label is accepted) |
InstallNamespace: tc.installNamespace, | ||
PackageName: "package", | ||
InstallNamespace: tc.installNamespace, | ||
ServiceAccountName: tc.serviceAccountName, |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
makes sense 👍
apiVersion: rbac.authorization.k8s.io/v1 | ||
kind: ClusterRole | ||
metadata: | ||
namespace: default | ||
name: test-clusterrole | ||
rules: | ||
- apiGroups: ["*"] | ||
resources: ["*"] | ||
verbs: ["*"] |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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!)
There was a problem hiding this comment.
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), |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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"` |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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)
apiVersion: rbac.authorization.k8s.io/v1 | ||
kind: ClusterRole | ||
metadata: | ||
namespace: default | ||
name: test-clusterrole | ||
rules: | ||
- apiGroups: ["*"] | ||
resources: ["*"] | ||
verbs: ["*"] |
There was a problem hiding this comment.
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!)
ced5993
to
b373ac5
Compare
e4c62fe
to
a03522c
Compare
a03522c
to
2e7d963
Compare
857a904
to
8933ba6
Compare
8933ba6
to
9b1e2e5
Compare
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. |
@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! |
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