Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

allow shared service users to determine which spaces their service is in #3931

Merged
merged 3 commits into from
Sep 12, 2024
Merged

allow shared service users to determine which spaces their service is in #3931

merged 3 commits into from
Sep 12, 2024

Conversation

Benjamintf1
Copy link
Member

Thanks for contributing to cloud_controller_ng. To speed up the process of reviewing your pull request please provide us with:

  • A short explanation of the proposed change:

allow shared serivce users to determine which spaces their service is in

  • An explanation of the use cases your change solves

Allows users of shared services to determine which spaces have access to a service without making a service_instaces request for each space they have access to.

  • Links to any other associated PRs

  • I have reviewed the contributing guide

  • I have viewed, signed, and submitted the Contributor License Agreement

  • I have made this pull request to the main branch

  • I have run all the unit tests using bundle exec rake

  • I have run CF Acceptance Tests

@Benjamintf1 Benjamintf1 mentioned this pull request Aug 15, 2024
Closed
@Benjamintf1 Benjamintf1 changed the title allow shared serivce users to determine which spaces their service is in allow shared service users to determine which spaces their service is in Aug 15, 2024
@philippthun
Copy link
Member

What about /service_instances/:guid/relationships/shared_spaces/usage_summary? Should this endpoint be adapted as well?

Also the docs need to be adjusted, i.e. docs/v3/source/includes/resources/service_instances/_list_shared_spaces.md.erb.

@Benjamintf1
Copy link
Member Author

Updated docs. I don't have a immense wish to expose usage_service, but it just gives number of bindings. Doesn't seem like a huge deal to me, and I understand viewing them simularly. I made requested change.

xandroc
xandroc approved these changes Sep 5, 2024
View reviewed changes
Copy link
Contributor

@xandroc xandroc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good!

philippthun added a commit to sap-contributions/cloud_controller_ng that referenced this pull request Sep 10, 2024
@philippthun
Filter out space and organization names based on permissions
ddc3801 
When a user has access to a shared service instance (i.e. read
permissions on any of the shared spaces), the guids of all shared spaces
are visible, but only those space and organization names the user is
allowed to read based on the given roles.

Example:

  DEVELOPER who is space developer in SPACE_1, SPACE_2 and SPACE_3
  shared SERVICE_INSTANCE from SPACE_1 to SPACE_2 and SPACE_3. For each
  space there is a dedicated space auditor (AUDITOR_1, AUDITOR_2 and
  AUDITOR_3).

  SPACE_1
  -------
    DEVELOPER (space developer)
    AUDITOR_1 (space auditor)
    SERVICE_INSTANCE

  SPACE_2
  -------
    DEVELOPER (space developer)
    AUDITOR_2 (space auditor)
    shared SERVICE_INSTANCE

  SPACE_3
  -------
    DEVELOPER (space developer)
    AUDITOR_3 (space auditor)
    shared SERVICE_INSTANCE

Original behavior (before PR cloudfoundry#3931):

  - AUDITOR_1 can see SPACE_2.guid + name and SPACE_3.guid + name
    => SPACE_2.name and SPACE_3.name should not be readable
  - AUDITOR_2 cannot see shared spaces
    => shared spaces should be readable
  - AUDITOR_3 cannot see shared spaces
    => shared spaces should be readable

Changed behavior (with PR cloudfoundry#3931):

  - AUDITOR_1 can see SPACE_2.guid + name and SPACE_3.guid + name
    => SPACE_2.name and SPACE_3.name should not be readable
  - AUDITOR_2 can see SPACE_2.guid + name and SPACE_3.guid + name
    => SPACE_3.name should not be readable
  - AUDITOR_3 can see SPACE_2.guid + name and SPACE_3.guid + name
    => SPACE_2.name should not be readable

New behavior (this change):

  - AUDITOR_1 can see SPACE_2.guid and SPACE_3.guid
  - AUDITOR_2 can see SPACE_2.guid + name and SPACE_3.guid
  - AUDITOR_3 can see SPACE_2.guid and SPACE_3.guid + name
@philippthun philippthun mentioned this pull request Sep 10, 2024
Merged
5 tasks
@Benjamintf1
Copy link
Member Author

@philippthun I tested your pr and it seemed to work fine too.

@Benjamintf1 Benjamintf1 merged commit d050fb5 into main Sep 12, 2024
9 checks passed
@Benjamintf1 Benjamintf1 deleted the shared-spaces-access branch September 12, 2024 20:38
ari-wg-gitbot added a commit to cloudfoundry/capi-release that referenced this pull request Sep 12, 2024
@ari-wg-gitbot
Bump cloud_controller_ng
79de900 
Changes in cloud_controller_ng:

- allow shared service users to determine which spaces their service is in
    PR: cloudfoundry/cloud_controller_ng#3931
    Author: Benjamin Fuller <[email protected]>
philippthun added a commit to sap-contributions/cloud_controller_ng that referenced this pull request Sep 13, 2024
@philippthun
Filter out space and organization names based on permissions
6be5087 
When a user has access to a shared service instance (i.e. read
permissions on any of the shared spaces), the guids of all shared spaces
are visible, but only those space and organization names the user is
allowed to read based on the given roles.

Example:

  DEVELOPER who is space developer in SPACE_1, SPACE_2 and SPACE_3
  shared SERVICE_INSTANCE from SPACE_1 to SPACE_2 and SPACE_3. For each
  space there is a dedicated space auditor (AUDITOR_1, AUDITOR_2 and
  AUDITOR_3).

  SPACE_1
  -------
    DEVELOPER (space developer)
    AUDITOR_1 (space auditor)
    SERVICE_INSTANCE

  SPACE_2
  -------
    DEVELOPER (space developer)
    AUDITOR_2 (space auditor)
    shared SERVICE_INSTANCE

  SPACE_3
  -------
    DEVELOPER (space developer)
    AUDITOR_3 (space auditor)
    shared SERVICE_INSTANCE

Original behavior (before PR cloudfoundry#3931):

  - AUDITOR_1 can see SPACE_2.guid + name and SPACE_3.guid + name
    => SPACE_2.name and SPACE_3.name should not be readable
  - AUDITOR_2 cannot see shared spaces
    => shared spaces should be readable
  - AUDITOR_3 cannot see shared spaces
    => shared spaces should be readable

Changed behavior (with PR cloudfoundry#3931):

  - AUDITOR_1 can see SPACE_2.guid + name and SPACE_3.guid + name
    => SPACE_2.name and SPACE_3.name should not be readable
  - AUDITOR_2 can see SPACE_2.guid + name and SPACE_3.guid + name
    => SPACE_3.name should not be readable
  - AUDITOR_3 can see SPACE_2.guid + name and SPACE_3.guid + name
    => SPACE_2.name should not be readable

New behavior (this change):

  - AUDITOR_1 can see SPACE_2.guid and SPACE_3.guid
  - AUDITOR_2 can see SPACE_2.guid + name and SPACE_3.guid
  - AUDITOR_3 can see SPACE_2.guid and SPACE_3.guid + name
philippthun added a commit that referenced this pull request Sep 16, 2024
@philippthun
Filter out space and organization names based on permissions (#3962)
1f30750 
When a user has access to a shared service instance (i.e. read
permissions on any of the shared spaces), the guids of all shared spaces
are visible, but only those space and organization names the user is
allowed to read based on the given roles.

Example:

  DEVELOPER who is space developer in SPACE_1, SPACE_2 and SPACE_3
  shared SERVICE_INSTANCE from SPACE_1 to SPACE_2 and SPACE_3. For each
  space there is a dedicated space auditor (AUDITOR_1, AUDITOR_2 and
  AUDITOR_3).

  SPACE_1
  -------
    DEVELOPER (space developer)
    AUDITOR_1 (space auditor)
    SERVICE_INSTANCE

  SPACE_2
  -------
    DEVELOPER (space developer)
    AUDITOR_2 (space auditor)
    shared SERVICE_INSTANCE

  SPACE_3
  -------
    DEVELOPER (space developer)
    AUDITOR_3 (space auditor)
    shared SERVICE_INSTANCE

Original behavior (before PR #3931):

  - AUDITOR_1 can see SPACE_2.guid + name and SPACE_3.guid + name
    => SPACE_2.name and SPACE_3.name should not be readable
  - AUDITOR_2 cannot see shared spaces
    => shared spaces should be readable
  - AUDITOR_3 cannot see shared spaces
    => shared spaces should be readable

Changed behavior (with PR #3931):

  - AUDITOR_1 can see SPACE_2.guid + name and SPACE_3.guid + name
    => SPACE_2.name and SPACE_3.name should not be readable
  - AUDITOR_2 can see SPACE_2.guid + name and SPACE_3.guid + name
    => SPACE_3.name should not be readable
  - AUDITOR_3 can see SPACE_2.guid + name and SPACE_3.guid + name
    => SPACE_2.name should not be readable

New behavior (this change):

  - AUDITOR_1 can see SPACE_2.guid and SPACE_3.guid
  - AUDITOR_2 can see SPACE_2.guid + name and SPACE_3.guid
  - AUDITOR_3 can see SPACE_2.guid and SPACE_3.guid + name
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@xandroc xandroc xandroc approved these changes

@philippthun philippthun philippthun approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@Benjamintf1 @philippthun @xandroc