cloudfoundry / cloudfoundry/cloud_controller_ng
Lack of possibility to read/GET standard service brokers as anyone other than admin.
Nobody has claimed this yet.
- Dominant language
- Ruby
- Stars
- 207
- Forks
- 373
- Avg merge
- 2d 12h
- Merged PRs (30d)
- 56
Description
Hey,
is it expected that I can't list all available service brokers as space developer by using /v3/service_brokers endpoint? Even if their access is global and I can create service instances out of them?
The documentation states, those are managed by admins, but nothing about their api visibility via GET method:
https://docs.cloudfoundry.org/services/managing-service-brokers.html
In the roles granularity it's distinguished on 'manage' level which in my opinion should rather has reflection on PUT/PATCH/POST methods than GET one.
https://docs.cloudfoundry.org/concepts/roles.html
Manage global service brokers
Manage space-scoped service brokers
# cf service-access
Getting service access as user...
broker: autoscaler
offering plan access orgs
autoscaler free all
broker: dbaas-broker
offering plan access space
Postgres Database Large limited MAIN (org: org1)
Postgres Database Medium limited MAIN (org: org1)
Postgres Database Small limited MAIN (org: org1)
broker: ecs-broker
offering plan access orgs
dynstrg usage all
dynstrg usage-encrypted all
broker: mongodb-broker
offering plan access orgs
mongodbent large3rs all
mongodbent medium3rs all
mongodbent small3rs all
mongodbent xsmall3rs all
mongodbent xxsmall3rs all
mongodbent xxxsmall3rs all
mongodbent-database default all
broker: rabbitmq-2-broker
offering plan access orgs
rabbitmqent-2 usage all
broker: rabbitmq-broker
offering plan access orgs
rabbitmqent usage all
broker: secret-store-broker
offering plan access orgs
secrets-store json all
broker: task-scheduler
offering plan access orgs
task-scheduler free all
service brokers endpoint shows only one broker that is space scoped. All other are not present.
# cf curl /v3/service_brokers | jq -r .
{
"pagination": {
"total_results": 1,
"total_pages": 1,
"first": {
"href": "https://api.appcloud.domain.com/v3/service_brokers?page=1&per_page=50"
},
"last": {
"href": "https://api.appcloud.domain.com/v3/service_brokers?page=1&per_page=50"
},
"next": null,
"previous": null
},
"resources": [
{
"guid": "e4561ebb-962b-4b2b-8e52-bfe734dbc8d6",
"created_at": "2017-11-23T13:22:20Z",
"updated_at": "2017-11-23T13:22:20Z",
"name": "dbaas-broker",
"url": "https://dbaas.domainapps-np.com/integration/api",
"relationships": {
"space": {
"data": {
"guid": "313fa79b-1cf6-40d6-b3bc-e242c1f8e38a"
}
}
},
"metadata": {
"labels": {},
"annotations": {}
},
"links": {
"self": {
"href": "https://api.appcloud.domain.com/v3/service_brokers/e4561ebb-962b-4b2b-8e52-bfe734dbc8d6"
},
"service_offerings": {
"href": "https://api.appcloud.domain.com/v3/service_offerings?service_broker_guids=e4561ebb-962b-4b2b-8e52-bfe734dbc8d6"
},
"space": {
"href": "https://api.appcloud.domain.com/v3/spaces/313fa79b-1cf6-40d6-b3bc-e242c1f8e38a"
}
}
}
]
}
I can see all of them via service offerings fields option:
# cf curl "/v3/service_offerings?fields["service_broker"]=guid,name" | jq -r [.resources[].relationships.service_broker.data.guid]
[
"ab004da7-5851-4c20-a440-0da259100058",
"8f3f5efb-8d86-49e0-bd1e-7863b2b9746c",
"e4561ebb-962b-4b2b-8e52-bfe734dbc8d6",
"a4e0d83a-a095-4ee8-ac71-4ac750aceef5",
"ec4d18c8-4199-40d4-9d97-709cab502387",
"07bdc680-8906-49c3-945e-c50b9cebcf6a",
"8c76628b-48a1-4d89-adc9-e98cdc3a9f3f",
"2313bc28-60da-4fc6-ac79-7f3897f47ed5",
"a4e0d83a-a095-4ee8-ac71-4ac750aceef5"
]
but I can't get them while trying with service_brokers endpoint directly:
# cf curl /v3/service_brokers/ab004da7-5851-4c20-a440-0da259100058
{"errors":[{"detail":"Service broker not found","title":"CF-ResourceNotFound","code":10010}]}
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the /v3/service_brokers collection and individual-resource endpoints, comparing their visibility with /v3/service_offerings and the documented service-broker roles. Trace the authorization behavior for space developers and admins, then verify that the chosen GET visibility policy is covered by tests and matches the documentation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- ruby
- Domain
- api, authorization
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100