Hi, Guillaume,

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.

Thanks,
Eric 

---

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

 

Hi Eric,

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 [1] or older "UAA integration with Kubernetes & Istio" [2] ?

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 [3]).

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,

[1] https://docs.google.com/document/d/1uPLab3F0LwbpV4ryGtaERfxdOx0Q4BCvbS8J-dVG29g/edit#heading=h.vkkr5or9sik8

[2] https://docs.google.com/document/d/1rE1CeMS6JD--O3bUyjVIA5JKrz8yfj4upgtoeKrH4ZA/edit

[3] https://docs.google.com/document/d/1mIMH4uEtIJkZjVa5mKWJoIAIeVyM4gVqO-Cx5JtYgtE

Guillaume.

On Fri, Jun 12, 2020 at 6:17 PM Eric Malm <emalm@...> wrote:

Hi, everyone,

I'm proposing to retire the incubating Perm project in the App Runtime PMC and to move its associated repos to the cloudfoundry-attic GitHub organization. We will plan to discuss and approve the proposal at the June 23rd App Runtime PMC meeting.

For context, the Perm project started in 2017 with the goal of providing a general authorization service for Cloud Foundry that could absorb and extend the authorization roles currently encoded in Cloud Controller. On account of difficulties integrating with the v2 Cloud Controller API, the project was placed on hiatus in late 2018, where it has remained to date. Although making authorization in the Cloud Foundry App Runtime more flexible and independent of existing components remains an important goal for the project, continual evolution in the identity space and the ongoing transition of the App Runtime to Kubernetes make it likely that any new efforts to achieve that goal will rely more directly on other community projects and technologies, such as the Open Policy Agent or Kubernetes RBAC itself.

Thanks,
Eric Malm, App Runtime PMC Lead