Enable adding a custom Property to each layer/host that gets created

[Miclain K Keffeler, MBA, CISSP]

Is your feature request related to a problem? Please describe.

No

Describe the solution you would like

For clients, it can be tough to parse the full string identifier to know where the PCF org/space/host came from. obviously we have the top level policy branch, but it's not easy to programmatically parse that string out.

As such, it would be nice to be able to add a custom property with hardcoded or variable value, so that you can simply look at the properties to determine things about the host. for example, a datacenter variable, to know what datacenter an org is in, or a orgName variable, so that with the GUID that gets created in Conjur, you also get the accompanying name of that org as an account property.

Describe alternatives you have considered

We could parse the policy branch out of the resource, but it's less than ideal for the web clients that need to parse this. Additionally we could list these values from the PCF APIs themselves, but really we need the information to persist in Conjur in some way, as that is where it belongs.

Additional context

We have multi data centers, so just the GUID alone isn't a guaranteed unique string. We can separate them via policy branches, but again, for web clients to parse the policy branch isn't super easy, because the resource identifiers can get very long.

[Geri Jennings]

@mkkeffeler thanks for this suggestion - we've thought about this for a long time. #71 is from 2019 - we haven't found a reasonable way to give the host-ids predictable, human-readable names, though.

Do you have a suggestion for how this would work? One idea that comes to mind for me, based on what you've written, is that we could enable specifying parameters on service instance creation. That would roughly work as follows:

1. Update command to create a Conjur service instance in a space so that it accepts parameters:

   cf create-service cyberark-conjur community conjur -c '{"param1":"value1","param2":"value2"}'
   

   As per the CF CLI docs, the input to the -c flag should be service-specific configuration parameters in a valid JSON object.

2. The service broker would take the parameters sent on the provision request and add them as annotations on the space policy resources, so the space policy would become:

---
# Policy for the Organization
- !policy
  # Organization GUID from the platform.
  # This may be obtained by running `cf org --guid {org name}
  id: cbd7a05a-b304-42a9-8f66-6827ae6f78a1
  body:
    # Layer to privilege an entire organzation to a resource
    - !layer

    # Policy for the Space
    - !policy
      # Space GUID from the platform.
      # This may be obtained by running `cf space --guid {space name}
      id: 8bf39f4a-ebde-437b-9c38-3d234b80631a
      body:
        # Layer to privilege an entire space to a resource
        # The service broker adds applications to this layer automatically.
        - !layer
           annotations:
             param1: value1
             param2: value2

    # Grant to add the Space layer to the Org Layer
    - !grant
      role: !layer
      member: !layer 8bf39f4a-ebde-437b-9c38-3d234b80631a

We could also potentially add these same annotations to the application identities created in policy - I don't see a clear mechanism for setting service-specific configuration on a bind request in the app manifest, but the cf bind-service command does allow this, so we could also investigate adding annotations to application-scoped identities on bind given specific bind service configuration JSON.

Let me know what you think about this idea (adding annotations to Conjur policy resources based on service configuration JSON), and whether you're looking for annotations just on the space layer or whether you're looking for finer grained annotations on application identities in policy, too.

[Boaz Michaely]

Published in CyberArk Aha! idea portal]

[Miclain K Keffeler, MBA, CISSP]

The above makes sense (and would love to continue the conversation on the Aha ideas portal, if I can get in that!). The other thing I was thinking was using an environment variable that every app that binds to the service has.

So for example, you could have a field in Opsman where you specify the path to the env car, "vcap.app.org_name" and then when an app binds to the service it pulls that equivalent environment variable, and sets it as an annotation in the policy. That's a little more flexible, and I think prone to less errors. But might not be easily done :)

[Miclain K Keffeler, MBA, CISSP]

another good idea off of this is to add annotations with the org and space name. those are friendly names that would be super useful to have.

[Miclain K Keffeler, MBA, CISSP]

would you guys be open to accepting a merge request that enabled this functionality optionally?

[Geri Jennings]

@mkkeffeler we'd definitely accept a contribution that adds this functionality. Before you add it, though, can you share more details about how you are going to retrieve the org/space name? It's been a little while since I looked into this, but when I last looked it required an API request that meant the service broker needed escalated permissions within the foundation - so we didn't choose to implement it then.

Before you invest time in adding this functionality, I'd love to sketch out what it will look like in this thread.

[Miclain K Keffeler, MBA, CISSP]

Yeah was doing that :)

Looking at service broker API https://github.com/openservicebrokerapi/servicebroker/blob/master/profile.md#cloud-foundry-context-object

The context object has the name of the org and space, along with guids. I can see in your code you guys use this object, so i think we would enhance this to get those params if they exist (since docs say only versions 2.15 and up have this), and then add them as annotations (need to update the templates used in this repo).

Make sense?

[Geri Jennings]

Sounds great! Thanks @mkkeffeler - please also keep in mind our contributor guidelines and in particular our requirement that you sign off on your commits (for more info, see here).

I look forward to seeing your contribution!!

[Miclain K Keffeler, MBA, CISSP]

Started this, but could use some feedback on testing, or help from someone with an env setup to do the testing. #248

[Geri Jennings]

Thanks @mkkeffeler - we'll take a look at this by EOD tomorrow. I think adding Rspecs was the right choice - if we have any feedback on whether more tests are needed, we'll add comments to the PR.