Hi All,

Currently only Space Developers have visibility on the /v2/apps/:guid/env
end point which backs the cf cli command `cf env APPNAME`.
Please let me know if you have any objections to allowing Space Managers
visibility of an app's environment variables.
This is something we would like to tackle soon to address some visibility
concerns.

-Dieu
CF CAPI PM

I debated long ago and still believe that a space manager should be able
to do everything a space developer can do. Could this be simplified just
by making that change? Or are there still reasons to limit a space
manager's abilities?

Mike

On Thu, Feb 25, 2016 at 3:54 AM, Dieu Cao <dcao(a)pivotal.io> wrote:

Hi All,

Currently only Space Developers have visibility on the /v2/apps/:guid/env
end point which backs the cf cli command `cf env APPNAME`.
Please let me know if you have any objections to allowing Space Managers
visibility of an app's environment variables.
This is something we would like to tackle soon to address some visibility
concerns.

-Dieu
CF CAPI PM

I'm glad to see this question. Why does a space manager role not include
all space developer permissions?

On Thu, Feb 25, 2016 at 11:51 AM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

I debated long ago and still believe that a space manager should be able
to do everything a space developer can do. Could this be simplified just
by making that change? Or are there still reasons to limit a space
manager's abilities?

Mike

On Thu, Feb 25, 2016 at 3:54 AM, Dieu Cao <dcao(a)pivotal.io> wrote:

Hi All,

Currently only Space Developers have visibility on the
/v2/apps/:guid/env end point which backs the cf cli command `cf env
APPNAME`.
Please let me know if you have any objections to allowing Space Managers
visibility of an app's environment variables.
This is something we would like to tackle soon to address some
visibility concerns.

-Dieu
CF CAPI PM

For some history this is the last discussion I recall having on the
subject:
https://groups.google.com/a/cloudfoundry.org/d/msg/vcap-dev/8Owzq9pzDSs/FzKX60KBdAkJ

Mike

On Sat, Feb 27, 2016 at 5:23 AM, Tom Sherrod <tom.sherrod(a)gmail.com>
wrote:

I'm glad to see this question. Why does a space manager role not include
all space developer permissions?

On Thu, Feb 25, 2016 at 11:51 AM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

I debated long ago and still believe that a space manager should be able
to do everything a space developer can do. Could this be simplified just
by making that change? Or are there still reasons to limit a space
manager's abilities?

Mike

On Thu, Feb 25, 2016 at 3:54 AM, Dieu Cao <dcao(a)pivotal.io> wrote:

Hi All,

Currently only Space Developers have visibility on the
/v2/apps/:guid/env end point which backs the cf cli command `cf env
APPNAME`.
Please let me know if you have any objections to allowing Space
Managers visibility of an app's environment variables.
This is something we would like to tackle soon to address some
visibility concerns.

-Dieu
CF CAPI PM

Something like custom roles and finer grained permissions is something we
would like to look at in the future, but the CAPI team is currently focused
on Tasks, v3, and soon Elastic Clusters, which will occupy us for the next
few months.

Thanks for sharing your point of view, Bernd. I think that makes sense
for certain deployments.

For the near term, if we do introduce this functionality, we may introduce
it with some feature flags, with the intention to some day deprecate that
feature flag when custom roles and finer grained permissions are in place.

Thanks for the feedback.

-Dieu
CF CAPI PM

On Sat, Feb 27, 2016 at 12:18 PM, Krannich, Bernd <bernd.krannich(a)sap.com>
wrote:

I guess it all depends on what you use CF for. I guess there’s a spectrum
between:

- Easy to use, developer-centric, company-internal environment: Make
it as easy as possible to grant people the permissions they need.
- Battle-hardened, multi-tenant (=multi-customer) enterprise platform
in highly regulated environments: Make it even possible to apply separation
of duties which I guess most often means less convenience.
- From Mike’s parallel mail: > What I don't want to see is a
gradual promotion of developer capabilities into Manager making it not
clear what Mangers can do and what they cannot.
- Yes, for this second type of usage I’d completely agree here.

One solution might be to allow operators to create and manage custom

roles, like we do with quotas. If the flexibility to implement business
rules is accessible under the "role" abstraction, we can afford
friendlier/more naive defaults.

That’s a great idea. I’m not clear if this is then a Cloud Controller API
discussion only or if – as it seems to me – this involves also efforts in
the UAA area.

Regards,
Bernd

From: Jesse Alford <jalford(a)pivotal.io>
Reply-To: "Discussions about Cloud Foundry projects and the system
overall." <cf-dev(a)lists.cloudfoundry.org>
Date: Saturday 27 February 2016 at 20:38
To: "Discussions about Cloud Foundry projects and the system overall." <
cf-dev(a)lists.cloudfoundry.org>
Subject: [cf-dev] Re: Re: Re: Re: Re: Re: Space Manager visibility of an
app's environment variables

Agreed: the simple/hierarchical model of permissions is less flexible and
composable. Having each roll have the permissions of the one "under" it
plus a new layer limits the business rules this can be used to implement.

I might even argue that managers shouldn't necessarily have auditor
permissions automatically.

The counter argument here is that we're basically either inflicting a
poor user experience or forcing clients to take on additional complexity to
give users intuitive experiences. One solution might be to allow operators
to create and manage custom roles, like we do with quotas. If the
flexibility to implement business rules is accessible under the "role"
abstraction, we can afford friendlier/more naive defaults.

On Sat, Feb 27, 2016, 11:24 AM Krannich, Bernd <bernd.krannich(a)sap.com>
wrote:

Sorry for broadening the discussion but for us it’s the other way round
for a similar use case: Having the CF admin role grants you developer
rights in all orgs and spaces (for example, you could `cf env` to retrieve
service instance credentials) which is something that’s IMHO not desirable
from a security/compliance perspective especially when running multiple
(external) customers on one CF instance. Customers typically don’t want
their providers to be able to be able to see all their data per default.
Sure, you can always grant yourself these roles as a CF admin but then
there’s audit logging to track those changes.

I guess one could go along a similar line of argumentation for space
manager and space developer.

For both cases the thing is: You can achieve the desired behavior by
granting more roles but if you combine roles there’s no way to achieve
separation of duties.

Regards,
Bernd

From: Matt Cholick <cholick(a)gmail.com>
Reply-To: "Discussions about Cloud Foundry projects and the system
overall." <cf-dev(a)lists.cloudfoundry.org>
Date: Saturday 27 February 2016 at 19:04
To: "Discussions about Cloud Foundry projects and the system overall." <
cf-dev(a)lists.cloudfoundry.org>
Subject: [cf-dev] Re: Re: Re: Re: Space Manager visibility of an app's
environment variables

This is a source of confusion for our end users as well. Users will have
the space manager role, but not the space developer role, and fail when
they first try to push an application.

On Sat, Feb 27, 2016 at 8:16 AM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

For some history this is the last discussion I recall having on the
subject:
https://groups.google.com/a/cloudfoundry.org/d/msg/vcap-dev/8Owzq9pzDSs/FzKX60KBdAkJ

Mike

On Sat, Feb 27, 2016 at 5:23 AM, Tom Sherrod <tom.sherrod(a)gmail.com>
wrote:

I'm glad to see this question. Why does a space manager role not
include all space developer permissions?

On Thu, Feb 25, 2016 at 11:51 AM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

I debated long ago and still believe that a space manager should be
able to do everything a space developer can do. Could this be simplified
just by making that change? Or are there still reasons to limit a space
manager's abilities?

Mike

On Thu, Feb 25, 2016 at 3:54 AM, Dieu Cao <dcao(a)pivotal.io> wrote:

Hi All,

Currently only Space Developers have visibility on the
/v2/apps/:guid/env end point which backs the cf cli command `cf env
APPNAME`.
Please let me know if you have any objections to allowing Space
Managers visibility of an app's environment variables.
This is something we would like to tackle soon to address some
visibility concerns.

-Dieu
CF CAPI PM

Thanks Dieu,

I don't have a problem with the change request. It just seems like an
oddly specific change given the current not very well defined set of roles
we have.

I'd like to see a more clear definition of what our roles should generally
be able to do and change CC to match the definition rather than making one
off specific changes like this customized by feature flag.

For example, I'm assuming this request must be coming from a customer that
believes a manager should be able to see everything in a space but not
change stuff.

Let me propose some definitions based on this requested change.

Manager:
* See everything.
* Change only user access.

Developer:
* See everything
* Change everything except for user access.

Auditor:
* See everything except for potentially sensitive data.
* Change nothing.

Under loose definitions like the ones above I would support giving
Managers access to app environment. However, by defining Manager like I
have are there other things a Manager should be able to see that they
currently cannot? If so now that we have a definition we can fix that.

In addition, once we have a clear definition for CC roles, it becomes
easier to make more useful feature flags to customize this functionality.
For example, instead of making a feature flag to allow managers to see
environment variables you can make a more general and clear flag that, for
example, denies managers the ability to see potentially sensitive data or a
feature flag that allows Auditors to see sensitive data if someone requests
that.

Thoughts?

Mike

On Sun, Feb 28, 2016 at 7:24 PM, Dieu Cao <dcao(a)pivotal.io> wrote:

Something like custom roles and finer grained permissions is something we
would like to look at in the future, but the CAPI team is currently focused
on Tasks, v3, and soon Elastic Clusters, which will occupy us for the next
few months.

Thanks for sharing your point of view, Bernd. I think that makes sense
for certain deployments.

For the near term, if we do introduce this functionality, we may
introduce it with some feature flags, with the intention to some day
deprecate that feature flag when custom roles and finer grained permissions
are in place.

Thanks for the feedback.

-Dieu
CF CAPI PM

On Sat, Feb 27, 2016 at 12:18 PM, Krannich, Bernd <bernd.krannich(a)sap.com

wrote:

I guess it all depends on what you use CF for. I guess there’s a
spectrum between:

- Easy to use, developer-centric, company-internal environment: Make
it as easy as possible to grant people the permissions they need.
- Battle-hardened, multi-tenant (=multi-customer) enterprise
platform in highly regulated environments: Make it even possible to apply
separation of duties which I guess most often means less convenience.
- From Mike’s parallel mail: > What I don't want to see is a
gradual promotion of developer capabilities into Manager making it not
clear what Mangers can do and what they cannot.
- Yes, for this second type of usage I’d completely agree here.

One solution might be to allow operators to create and manage custom

roles, like we do with quotas. If the flexibility to implement business
rules is accessible under the "role" abstraction, we can afford
friendlier/more naive defaults.

That’s a great idea. I’m not clear if this is then a Cloud Controller
API discussion only or if – as it seems to me – this involves also efforts
in the UAA area.

Regards,
Bernd

From: Jesse Alford <jalford(a)pivotal.io>
Reply-To: "Discussions about Cloud Foundry projects and the system
overall." <cf-dev(a)lists.cloudfoundry.org>
Date: Saturday 27 February 2016 at 20:38
To: "Discussions about Cloud Foundry projects and the system overall." <
cf-dev(a)lists.cloudfoundry.org>
Subject: [cf-dev] Re: Re: Re: Re: Re: Re: Space Manager visibility of
an app's environment variables

Agreed: the simple/hierarchical model of permissions is less flexible
and composable. Having each roll have the permissions of the one "under" it
plus a new layer limits the business rules this can be used to implement.

I might even argue that managers shouldn't necessarily have auditor
permissions automatically.

The counter argument here is that we're basically either inflicting a
poor user experience or forcing clients to take on additional complexity to
give users intuitive experiences. One solution might be to allow operators
to create and manage custom roles, like we do with quotas. If the
flexibility to implement business rules is accessible under the "role"
abstraction, we can afford friendlier/more naive defaults.

On Sat, Feb 27, 2016, 11:24 AM Krannich, Bernd <bernd.krannich(a)sap.com>
wrote:

Sorry for broadening the discussion but for us it’s the other way round
for a similar use case: Having the CF admin role grants you developer
rights in all orgs and spaces (for example, you could `cf env` to retrieve
service instance credentials) which is something that’s IMHO not desirable
from a security/compliance perspective especially when running multiple
(external) customers on one CF instance. Customers typically don’t want
their providers to be able to be able to see all their data per default.
Sure, you can always grant yourself these roles as a CF admin but then
there’s audit logging to track those changes.

I guess one could go along a similar line of argumentation for space
manager and space developer.

For both cases the thing is: You can achieve the desired behavior by
granting more roles but if you combine roles there’s no way to achieve
separation of duties.

Regards,
Bernd

From: Matt Cholick <cholick(a)gmail.com>
Reply-To: "Discussions about Cloud Foundry projects and the system
overall." <cf-dev(a)lists.cloudfoundry.org>
Date: Saturday 27 February 2016 at 19:04
To: "Discussions about Cloud Foundry projects and the system overall."
<cf-dev(a)lists.cloudfoundry.org>
Subject: [cf-dev] Re: Re: Re: Re: Space Manager visibility of an app's
environment variables

This is a source of confusion for our end users as well. Users will
have the space manager role, but not the space developer role, and fail
when they first try to push an application.

On Sat, Feb 27, 2016 at 8:16 AM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

For some history this is the last discussion I recall having on the
subject:
https://groups.google.com/a/cloudfoundry.org/d/msg/vcap-dev/8Owzq9pzDSs/FzKX60KBdAkJ

Mike

On Sat, Feb 27, 2016 at 5:23 AM, Tom Sherrod <tom.sherrod(a)gmail.com>
wrote:

I'm glad to see this question. Why does a space manager role not
include all space developer permissions?

On Thu, Feb 25, 2016 at 11:51 AM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

I debated long ago and still believe that a space manager should be
able to do everything a space developer can do. Could this be simplified
just by making that change? Or are there still reasons to limit a space
manager's abilities?

Mike

On Thu, Feb 25, 2016 at 3:54 AM, Dieu Cao <dcao(a)pivotal.io> wrote:

Hi All,

Currently only Space Developers have visibility on the
/v2/apps/:guid/env end point which backs the cf cli command `cf env
APPNAME`.
Please let me know if you have any objections to allowing Space
Managers visibility of an app's environment variables.
This is something we would like to tackle soon to address some
visibility concerns.

-Dieu
CF CAPI PM