Cloud Foundry Application Entitlement is Scalable

izgeri commented 5 years ago

ETA for completion of this epic: Feb 21, 2019 Confidence level of ETA accuracy: 75%

Objective

Organizations using the service broker may find it difficult to entitle applications to access Conjur resources at scale since the host ID in Conjur is unknown until the application is pushed to CF and bound to a Conjur service instance. However, if an organization pre-creates the org and spaces that the applications will be deployed to, they will know in advance what the org / space GUIDs are where the app will be deployed and will be able to grant privilege to access Conjur resources to apps that will be deployed to that org and/or space.

Happily, PCF updated their service broker functionality as of Version 2.0 so that on a bind request the service broker is sent the org and space GUIDs. In light of this, we will revise the service broker's response to a bind request to include adding the host identity to layers for the org and space (with IDs given by the org/space GUIDs). We expect this will make it easier to manage privilege for CF applications in Conjur at scale while maintaining segregation of duties.

Open questions:

Is org/space in the bind context only available in PCF? If this is also available in CF, what versions of CF support org/space information supplied on bind?
- Org / space in context was added to CF in this commit and added to the CAPI release in this commit
- Supported as of CAPI 1.30.0 (confirmed by CF dev team) which is used in PCF 1.12.0+
- Other notes: support for OSB 2.13 was only added in CAPI 1.43.0 - we likely can't support CF instances using an earlier version
Are the org/space GUIDs supplied on bind those of the service instance or of the application? If it is the org/space of the service instance, we may want to specifically advise users to provision a service instance per org/space for our SB.

Supported versions for update:

Conjur Versions Supported by Update: EE 5.0+, OSS 1.0+ PCF Versions Supported by Update: 1.12+ CF Versions Supported by Update:

To use the auto org/space functionality your CF installation must have CAPI 1.30.0+
- To use multi-buildpack functionality your CF installation must have Diego 1.15.3+ and you must use CF CLI 6.38+
- To use OSB API 2.13 compatible service brokers, your CF installation should have CAPI 1.43.0+
- Version 2.0.0 of the buildpack has the limitation that it only supports Spring Boot versions less than 1.4 (eg versions that place configuration stored in src/main/resources in root at build time)

Story Breakdown

Preparation

[x] XDD - Parent of cyberark/conjur-service-broker#66
[x] Parent of conjurinc/appliance#598 - Developer/Test PCF environment exists
[x] Parent of cyberark/conjur-service-broker#68 - Integration tests are run against actual PCF installation

Development

[x] Parent of cyberark/cloudfoundry-conjur-demo#25 - Local demo runs correctly on recent version of PCF dev
[x] Parent of #63 - On bind, service broker loads policy for app layer and bind host into the space policy
[x] Parent of #70 - On Provision, Service broker ensure policy exists for Organization and Space
[x] Parent of #67 - Applications receive the URL of a Conjur follower on bind
[x] Parent of #74 - Upgrade rack and sinatra
[x] Parent of #79 - Bind integration test is run for Conjur V5 and V4
[x] Parent of cyberark/cloudfoundry-conjur-buildpack#17 - Buildpack is converted to supply buildpack
[x] Parent of #83 - Service broker health check validates follower URL
[x] Parent of cyberark/cloudfoundry-conjur-buildpack#22 - Buildpack uses profile.d directory
[x] Parent of #88 - CONJUR_FOLLOWER_URL handles empty values
[x] Parent of #90 - Service Broker returns empty follower URL as appliance URL to app
[X] Parent of #92 - Server Broker Integration Test App uses Supply Buildpack
[x] Parent of #97 - Preserve policy is on by default
[x] Parent of #99 - Service broker is not shareable by default

Demonstration

[x] Parent of cyberark/cloudfoundry-conjur-demo#23 - Local demo is updated to allow entitling the app based on app layer, org layer, or space layer
[x] Parent of cyberark/cloudfoundry-conjur-demo#26 - Rack and Sinatra gems have been updated
[x] Parent of cyberark/cloudfoundry-conjur-demo#27 - Remote demo is updated to allow entitling the app based on app layer, org layer, or space layer

Documentation

[ ] Parent of cyberark/docs-cyberark-conjur-service-broker#5 - Documentation is updated with info on 1.0.0 tile release
[X] Parent of cyberark/conjur-org#311 - PCF tutorial is updated to leverage the new service broker and buildpack functionality

Release

[x] Parent of conjurinc/cloudfoundry-conjur-tile#11 - Tile v1.0.0 is released

XA

[x] Parent of #72 - The scalable PCF integration has passed XA

Future work:

[ ] #71 - Service Broker Policy uses Human-Readable Names
[ ] cyberark/cloudfoundry-conjur-buildpack#18 - Buildpack is smarter about where to find secrets.yml
[ ] #85 - Consider using app-guid to identify bind !host rather than binding_id

izgeri commented 5 years ago

Copied from duplicate issue conjurinc/appliance#507

For PCF 2.0 and above, hosts need to be add-able to predictable layers in Conjur that correspond to org & space (using meta-data sent with the bind request).

Without a solution, Conjur becomes a very unwieldy manual process that cannot work at scale.

See 365 doc "Cloud Foundry" / "PCF Scalability Conversation Notes" for more details.

izgeri commented 5 years ago

Copied from duplicate issue conjurinc/appliance#507

For PCF 2.0 and above, hosts need to be add-able to predictable layers in Conjur that correspond to org & space (using meta-data sent with the bind request).

Without a solution, Conjur becomes a very unwieldy manual process that cannot work at scale.

See 365 doc "Cloud Foundry" / "PCF Scalability Conversation Notes" for more details.

cyberark / conjur-service-broker