toggle quoted message
Show quoted text
The App Runtime PMC approved the proposal to retire the Perm project at today's PMC meeting. The corresponding project repositories are now located in the CF attic; see https://github.com/cloudfoundry-attic?q=perm
the full list.
From: cf-dev@... <cf-dev@...> on behalf of Guillaume Berche via lists.cloudfoundry.org <bercheg=gmail.com@...>
Sent: Tuesday, June 23, 2020 9:28 AM
To: cf-dev <cf-dev@...>
Subject: Re: [cf-dev] Proposal to retire the Perm project in the App Runtime PMC
Thanks for the clarifications!
Le mar. 23 juin 2020 à 17:08, Eric Malm <emalm@...
> a écrit :
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 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@...
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.
Eric Malm, App Runtime PMC Lead