Reduce excessive GH authorization request

[Marvin Hansen]

Which version of kubefirst are you using?

2.4

Which cloud provider?

None specific

Which DNS?

None specific

Which installation type?

CLI

Which distributed Git provider?

GitHub

Did you use a fork of gitops-template?

No

Which Operating System?

None specific

What is the issue?

I tried to install Kubefirst and was greeted with a bizarre and way to broad request to my GH account. See below.

What in the world have you guys smoked to even come up with this flagrant violation of basic human rights?

Non-starter, non-negotiable, and not going to happen.

Code of Conduct

• I agree to follow this project's Code of Conduct

[John Dietz]

our permissions are not excessive when you use new bot accounts for cloud, git, and dns during installation as we advise. our team works tirelessly to ensure you get a secure and free platform, and your public comments are ignorant to how the system works and weren't appreciated.

i see this issue is related to adding kargo to kubefirst. i think this begins the misunderstanding of kubefirst. kargo shouldn't need any access to the platform at all, nor any credentials that we use for provisioning and administration of the system. if git credentials are needed for kargo to access any git repos, any keys could be added to your new vault, pulled by external-secrets, and provided to kargo. kargo doesn't need to get into the business of our platform provisioning mechanics. kargo would also not go in the kubefirst platform, we already offer argo as batteries included ci. to get kargo into kubefirst users hands, it would instead be an addition to the gitops-catalog. the gitops-catalog is where apps go that you want running in kubefirst after an install. it's also open source, community driven, and has all of the secret management mechanics described above already established for a seamless user experience.

back to your issue here though. what you need to understand is that we're establishing a platform where your humans don't need access to your git repo settings, they only need your new gitops repo. when you establish a new org, cloud user (or role), github/gitlab user, and run an installation, the only access to your new argo workflows, argo cd, vault, kubefirst applications, as well as your 2 new git repositories: gitops and metaphor is that singular bot account.

that singular entity will have access to that platform as a user named kbot which is associated with your bot account. kubefirst will have access to nothing of yours as a human installer. you as a human will not yet have access to the system yet. just kbot, and the platform. then you add yourself to the platform using automated iac. then the rest of your team. everyone will have sso from minute zero because of the oidc clients that we provide to all of the platform apps.

humans are bad at managing git repo settings. kubefirst, and it's really atlantis/terraform not kubefirst, has to do a lot to be effective at getting rid of your human access. we start you out with 2 repos, you take it from there.

if the system needs to build and administer your github org, it's repos, it's teams and access levels, its own gitops platform, and run gitops ci commits with signatures, and create webhooks for atlantis, all on a bot's identity in your new org, if there's permission you would remove, we'll consider the use case, but i'm guessing you were just using all your personal credentials instead for everything and got spooked.