Hi, I'm wondering why we use ClusterRole and ClusterRoleBinding in the Propeller service. We have security concerns because the Flyte service is installed in a K8S cluster that also hosts other services. On GitHub , I can see that in the master branch, we have already modified this, but we haven't officially released the change yet. @fierce-monitor-77717

You can have cluster/namespace scopes for Propeller service. It can be changed in the values file: https://github.com/flyteorg/flyte/blob/master/charts/flyte-core/values.yaml Cluster role might be required if you want to run workloads across different namespaces and don’t want separate role/YAML file. But if your workload is in a single namespace and all workloads are to be run within that, you should go with namespace binding

We have flyte namespace for the flyte services, and one more namespace for running the tasks. The link you sent is for the master, but still we don't have this option in old releases. Thanks for your help.

My take would be to take the task running to the flyte namespace, unless there is a reason not to or belongs to some other team/verticle that you have no control over (in that case you can create specific

RoleBinding

for a namespace with the required permission ). That way you can just create a role binding for a particular namespace as below:

kind = "Role"

That will limit the scope. Its worth the extra effort as scope creep is a real issue, and might come back to bite when no one is looking

@acceptable-knife-37130 I did it, and the deployment finished. I defined a namespace flyte-staging, and also domain staging. The resources created under flyte-staging. Now I tried to create a new task, but it failed since he is looking for flyte cluster and not flyte-staging. I'm wondering what am I missing?

Check the

namespace

in values.yaml. https://github.com/flyteorg/flyte/blob/master/charts/flyte-core/values.yaml Depending on your cloud provider change the values in the below folder: https://github.com/flyteorg/flyte/tree/master/charts/flyte-core Lot of the namespace are dynamically loaded as variables. you might need to modify those

Thanks @acceptable-knife-37130 I succeeded in installing

flyte-core

with namespace scope! However, tasks are not running because FlytePropeller throws the following errors: •

Failed to watch *v1.Pod: failed to list *v1.Pod: pods is forbidden: User "system:serviceaccount:flyte-staging:flytepropeller" cannot list resource "pods" in API group "" at the cluster scope

•

Failed to list *v1alpha1.FlyteWorkflow: <http://flyteworkflows.flyte.lyft.com|flyteworkflows.flyte.lyft.com> is forbidden: User "system:serviceaccount:flyte-staging:flytepropeller" cannot list resource "flyteworkflows" in API group "<http://flyte.lyft.com|flyte.lyft.com>" at the cluster scope

It seems that when using a

Role

and

RoleBinding

, the

flytepropeller

service account doesn't have sufficient permissions to list Pods or CRD resources across the cluster. Once I switched back to using a

ClusterRole

and

ClusterRoleBinding

, everything started working again. I’m wondering if anyone has successfully configured Flyte to run in namespace-scoped mode (without cluster-wide permissions)?

Awesome !!!🙌