I watched the recent "ZipRecruiter's Flyte Path" presentation and a lot of it resonated with our efforts to deploy and evaluate Flyte at my work. I'm curious about the reduced permissions mentioned at this . We'd like to reduce the permissions of the ClusterRole too, if possible. I thought Seth mentioned in the video talking to the Flyte team about this, but I can't find the mention of that now. If I didn't imagine that part, was any info about a reduced permission set recorded somewhere?

I think @Seth Miller could help out here.

also cc @Yee who cares deeply about this

geoff can you explain where you’re looking to cut specifically?

I don't have a specific set of things to remove. I heard that mention in the video and was interested in knowing what could be removed. Looking at the resources and verbs (

*

) of the

ClusterRole

in the flyte-core helm chart, I wonder why flyte needs complete control of resources like secret, role, rolebinding, and serviceaccount. Are permissions like this needed so flyte can create the configured cluster resources when it creates a new namespace or are there other features that require creating/deleting these resources?

nope that would be it

Then it would be nice to understand the subset of permissions (resource types and verbs) that flyte needs when cluster resource controller is applying zero resources in new namespaces. Then it's clear that if we want Flyte to create a Secret resource in the namespaces rather than deploying it ourselves in some other way, then we'll need to give Flyte's ClusterRole that permission. Right now when an infrastructure team asks us why the role's permissions are so broad we can only 🤷.