Re: Proposal to retire the Perm project in the App Runtime PMC
I was referring to identity concepts and protocols (such as OAuth, OIDC, RBAC, and SPIFFE) generally when I mentioned evolution within the identity space. I don't believe there are any specific proposals in the community yet about how to proceed with the next round of Perm-like work.
I certainly expect that part of working out useful ways to separate and to refine the authorization roles in Cloud Controller will be to ensure backwards compatibility with the existing CF CLI and CC API authentication and authorization workflows, and that app developers in particular would be insulated from the details of K8s RBAC, OPA, or other systems that may implement these identity and auth capabilities. Platform operators would likely have more direct exposure to those details, though, to the extent that they would be responsible for deploying those systems, administering them, and connecting them to an external identity provider.
From: cf-dev@... <cf-dev@...> on behalf of Guillaume Berche via lists.cloudfoundry.org <bercheg=gmail.com@...>
Sent: Wednesday, June 17, 2020 12:42 PM
To: cf-dev <cf-dev@...>
Subject: Re: [cf-dev] Proposal to retire the Perm project in the App Runtime PMC
Thanks for sharing the plans for perm project with the community. Can you please remind me where more information can be found related to the "evolution of the identity space" ? I could yet not find mention of them into the CF4K8s index doc  or older "UAA integration with Kubernetes & Istio"  ?
More precisely, as I understand that CF4K8S will require Cf operators to be authenticated against K8S, I did not yet see the confirmed plans to require CF users (developers and admins) to be registered into K8S in order to grant them permissions on K8S entities using native technologies such as RBAC or Open Policy Agent (only found so far an exploration of CRD UX into ).
I feel that maintaining compatibility with CF CLI and CF CC API while migrating to Cf4K8S is an important part of CF value proposition which protects CF user base (developers and admins) from K8S complexity and preserves CF simple developer experience. Is there ways the OPA or K8S RBAC would indirectly be used from CF CLI and APIs to fulfill perm project use-cases, without requiring these users to ramp up with associated K8S complexity and cognitive load ?
Thanks in advance for your help,
On Fri, Jun 12, 2020 at 6:17 PM Eric Malm <emalm@...> wrote: