I watched the recent "ZipRecruiter's Flyte Path" p...
# flyte-deployment
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

part of the video

. 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 Salmon we are actually working on Flyte slim version
ya so ZipRecruiter did that themselves, but we are working on making that a standard now
geoff can you explain where you’re looking to cut specifically?
i started taking a look but i’m not actually sure where to do it. when i did this last year i ended up removing a ton of functionality to make it happen
so not sure what’s needed in the slim use-case and what’s not
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
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
the cluster resource controller
that is a cron job (I think it’s no longer a K8s CronJob but still runs periodically) that configures the attached clusters accordingly.
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 🤷.
It sounds like this is one aspect of what the slim version is, so I'm happy to hear about that. Just wrote the above to explain my motivation.
Is there any other info on Flyte slim publicly available?