Re: Issues with Namespace and Cluster Scoped Permissions

[Alex Greene]

Hello Ric,

Thanks for reaching out and for using OLM.

OLM allows an operator to define both namespaced and ClusterScoped permissions. I am not aware of a templating problem, could you share the CSV that you created so I can investigate?

Thanks,

Alex

On Tue, Jul 28, 2020 at 2:02 PM Ric Featherstone <ric...@japeoh.com> wrote:

I'm developing an operator that works mainly with namespace scoped resources and have defined the required permissions in role.yaml and role_binding.yaml.

I also need to create a service account that can create tokenreviews at the cluster scope so have this in in clusterrole.yaml and clusterrole_binding.yaml.

Everything works fine when I deploy directly with the manifests, the issues come when I use OLM. When I generate the bundle the CSV has the clusterrole name for the serviceAccountName in the clusterPermissions. If I manually change this to the correct service account it makes no difference, the cluster permissions are not applied to the operator service account.

Is there a problem with the templating causing the incorrect serviceAccountName?

Why are the cluster permissions not applied when I manually correct this?

Am I doing this wrong, is it namespace or cluster wide permissions and not both?

Thanks

--
You received this message because you are subscribed to the Google Groups "Operator Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to operator-framew...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/operator-framework/f1321e09-65ba-426c-b64f-07e3e66b7c56n%40googlegroups.com.

--

Alexander Greene
He - Him - His

Software Developer

C: 412-508-5479

IRC: agreene

[Richard Featherstone]

Thanks for your response, I figured this out; user error.

When deploying directly using the manifests I was using the same clusterrole for the operator service account (so it had the permissions it was granting) and then looking up the clusterrole in the ansible role to assign to the service account created by the role.

When I created a bundle and deployed using olm, a generated name was used for the clusterrole, therefore it was failing to look it up. The confusion was because the error was a 403.

There is a templating issue when running `operator-sdk generate bundle` as the clusterPermissions serviceAccountName is the clusterrole name and not the operator service account name.

I was going to open an issue on github for this. The project is currently internal so I need to create a shareable example of the issue first.

Thanks,

R

[Eric Stroczynski]

Yes please create an issue when you can. This is something I'd like to fix asap if this is a generator issue.

--

You received this message because you are subscribed to the Google Groups "Operator Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to operator-framew...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/operator-framework/AM6PR03MB55572D8A399014C9D0BF5AF7CB700%40AM6PR03MB5557.eurprd03.prod.outlook.com.

--

Eric Stroczynski

Software Engineer
Operator SDK Team
Red Hat Inc. San Francisco Office

[Ric Featherstone]

Issue

Example Project

[Ric Featherstone]

I've just seen the PR for this and have a question related to behaviour and idiomatic use of the sdk.

I'm working on an opertor for managing the trust between k8s and vault. For this is need a service account that has create tokenreviews permissions.

Initially the I was just creating the manifests for this service account and it's cluster permissions and when I generated the bundle it almost worked aside from the service account name. I then thought that the manifests should only be for the deployment and operation of the operator, so refactored to create the service account when a cr was created. I wasn't exactly happy with this because the operator service account needed the permissions to be able to grant them but thought this was the approriate way to do things.

Reading the PR above, it looks like the sdk will happily create any defined service accounts and permissions as well as the resources required for the operator. This works better for my use case and I'll revert to my original approach to define additional service accounts and permissions to be created at operator deployment if this a correct use of the tooling.

The PR also states only rbac and service accounts have this behaviour. Are there plans to extend this to other resources in the future, CronJobs for service account token rotation for example?

Thanks

[Eric Stroczynski]

Great question. To clarify: that PR ties all permissions in a CSV to a (cluster) role bound to a CSV deployment strategy’s service account, and writes all other RBAC objects and service accounts to the manifests directory. The SDK does not actually create any of these manifests; it writes those passed into the generator into the manifests directory for OLM to manage as a bundle/package manifests.

There are plans to write all objects that OLM supports to the manifests directory, see 

https://github.com/operator-framework/operator-sdk/issues/3494.

To view this discussion on the web visit https://groups.google.com/d/msgid/operator-framework/cb72894f-06c2-40c9-9cc4-72abf5a8c0a3n%40googlegroups.com.

[Ric Featherstone]

I need to go back and look into this but iirc I was previously seeing two service accounts created where cluster permissions and permissions in the csv referenced two different service account names.

I don't know if this is limited to two, or whether I could add as many service accounts as I wanted and they would be created at operator deploy time (I'll have a go at this later but given it a list of rules expect this would work).

What I wanted to know is, 'is this a valid use of the sdk or am I abusing the tooling?'. When deploying the operator, should you only create the resources required for the operator to run and other resources should be created when the operator runs?

[Daniel Messer]

There will always be a balance to strike here. In general it is preferred that the Operator handles the lifecycle of all resources that it creates at runtime and have something like OLM only deploy the resources that are necessary to get the Operator started. On the other hand, if the lifecycle is really simplistic for those resources (e.g. they are only ever created once and are fairly static) then there is a benefit of having OLM create those for you, if in turn, you can lower the required RBAC for your Operator.

 

--
You received this message because you are subscribed to the Google Groups "Operator Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to operator-framew...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/operator-framework/26dd8114-faf4-4285-a5ff-bcb634624a8dn%40googlegroups.com.

--

Daniel Messer

Product Manager Operator Framework & Quay

Red Hat OpenShift

[Ric Featherstone]

Perfect, thank you for that response. I think it matches my thinking; that this is not strictly how things should be done but that it can be justified and for this use case make sense

[Ric Featherstone]

I am currently migrating what I've been working on to v1.0.0-alpha.2 and could use some advice.

I've added the clusterrole and binding to rbac and am trying to add the service account.

I've created a serviceaccount folder, added the manifest and a kustomization.yaml and added the folder to bases in default/kustomization.yaml.

When I run `make bundle` the expected manifests are created in bundle/manifests but I get an error about meta.namespace being forbidden on service accounts when the bundle is validated.

I'm not familiar with Kustomize, is there a way to exclude the service account from having the default namespace added?

[Daniel Messer]

This is due to the fact that OLM will create the Service Account in the namespaces for you, depending on where your Operator watches.

--
You received this message because you are subscribed to the Google Groups "Operator Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to operator-framew...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/operator-framework/e45b1fa0-0f2c-4bfc-9c9f-fe6dfa6ad434n%40googlegroups.com.

[Ric Featherstone]

I understand the why, the issue is how to stop it.

In the config directory, I have added a serviceaccount folder, added a kustomization.yaml with resources list for the two service accounts, added this folder to bases in default/kustomization.yaml.

The service account manifests are picked up correctly but because default/kustomization.yaml adds the namespace to resources it's added to the service account manifests.

This final piece, where kustomize adds the namespace to the manifests is what I need help to prevent.

Thanks

[Daniel Messer]

+SDK

To view this discussion on the web visit https://groups.google.com/d/msgid/operator-framework/844144c9-18a4-4d37-ae82-51ffb3f93460n%40googlegroups.com.

[Eric Stroczynski]

Specifically for generating bundles, you can add your new resources to config/manifests/kustomization.yaml, which is a level up from the config/default/kustomization.yaml that applies namespaces to all resources.

In general I am not sure if kustomize "supports" non-namespaced resources explicitly. This issue might be related.

To view this discussion on the web visit https://groups.google.com/d/msgid/operator-framework/844144c9-18a4-4d37-ae82-51ffb3f93460n%40googlegroups.com.

[Ric Featherstone]

Perfect, that worked like a charm and was exactly what I needed.

Many thanks

[Eric Stroczynski]

Happy to help!

To view this discussion on the web visit https://groups.google.com/d/msgid/operator-framework/0dae7663-30d0-4ad1-909c-6af51838cc5an%40googlegroups.com.

[Ric Featherstone]

I think I've spoken to soon and it's not going to work how I thought it was and I'm going to have to refactor to get the sa and rbac when the operator runs.

Pre v1 of the sdk the clusterrole.yaml and clusterolebinding.yaml were picked up and added to the cluster permissions in the csv now they are not.

Before I start the refactoring, is there a way to do this?

Thanks

[Eric Stroczynski]

Try adding a clusterrolebinding

To view this discussion on the web visit https://groups.google.com/d/msgid/operator-framework/c76daaa9-430d-4f75-8217-e383f367c051n%40googlegroups.com.

[Ric Featherstone]

OK, was a long day yesterday and I wasn't clear as I got myself in a muddle.

If I create the clusterrolebinding using the default serviceaccount, it gets mapped into the csv.

If I map it to the serviceaccount I create, it doesn't get mapped into the csv.

This is probably as expected, but when I did this prior to v1, it did get mapped into the csv and it used the serviceaccount name defined in the binding.

Having looked at this again today with a clear head, I understand what is happening, why and how to do what I want.

I can create the service account and cluster role, allowing olm to create the service account in the correct namespace.

This works, as these are static and shared no matter how many crs are created.

Then I just need to create the clusterrolebinding when the operator processes a cr.

It should all work with make deploy and both molecule test scenarios and given the additional service account is not mapped into the csv, it not longer feels likes I'm exploiting something.

Thanks for your help and advice on this one

[Eric Stroczynski]

Yes that pretty much sums it up! Any (cluster) role bound to a service account that is referenced by a CSV’s deployment will be added to the CSV’s (cluster) permissions; all other RBAC will be directly written to the bundle as manifests to be applied by OLM.

To view this discussion on the web visit https://groups.google.com/d/msgid/operator-framework/e7d5a835-ed5e-4d64-9a6a-654ae6884e5fn%40googlegroups.com.