cloudfoundry-community/portcullis

Streamlining service broker setup in large Cloud Foundry environments

portcullis

The goal behind Portcullis is to make it easier for CF service broker admins and CF admins to handle running services in Cloud Foundry. The observation here is that in large Cloud Foundry environments, the people managing services are not typically the same people with the adminstrative rights to Cloud Foundry - and that makes sense. However, this communication can be the bottleneck in getting services up and running. Portcullis seeks to wrap the permissions system of the UAA/Cloud Foundry to provide a handle for which service broker devs/admins can manage the access of their own broker. Also, security groups will be opened to users as bindings are made to service instances.

How Do I Run It?

The dependencies are vendored, so cloning the repo and either go runing the main.go file or go building the project will start the program. A configuration file is required - look in assets/examples for an idea of how to make one (docs at a later time), and set the PORTCULLIS_CONFIG environment variable to the path at which you have created the configuration.

This project is still in early development, so the master branch may contain buggy code until a preliminary set of features has been completed.

portcullis's Issues

How do I build it? What dependencies? How do I run it? How do I debug it? Oh... what's it do? And where are the files? And can we change the license?

README?

Consider collaboration with sec-group-broker-filter

Thanks for sharing this work.

In case this went unnoticed Orange has contributed very similar work at https://github.com/orange-cloudfoundry/sec-group-broker-filter

If different programming languages (java vs go-lang) are not an obstacle, it would be interesting to consider collaborating since both efforts that seem to address the same use-cases. Note that the sec-group-broker-filter repo also contains start of a generic framework for broker facades/filters for supporting other uses-cases beyond opening security groups.

Focusing on portcullis, I wonder the rationale for the address mapping that is documented at https://github.com/cloudfoundry-community/portcullis/blob/master/docs/broker_communication.png (and the associated operational burden to maintain a db)

Is this mapping necessary to support dynamic mapped service broker registration (that operations would perform through a dashboard UI)?

In sec-group-broker-filter, we're first planning to support multiple mapped service brokers through deploy-time configuration see orange-cloudfoundry/sec-group-broker-filter#19 and thus currently avoid maintaining state within the sec-group-broker-filter (i.e. no DB is required).

We'd be happy to further exchanges on how to collaborate on this idea.

Thanks in advance,

Guillaume.

/CC @s-bortolussi @poblin-orange