Event log may contain sensitive service parameters

[youngm]

When I look at event logs for actee_type=service_instance I notice service parameters passed in at service creation being logged. These parameters can container sensitive information. I'm not sure how locked down access to events are in the CC but in my org we send all events out to an audit log that has a different security profile than CC. We're now redacting the parameters when sent to our audit log but other CF users might not be aware these parameters are getting logged. You may want to consider redacting parameters in event logs.

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this. You can view the current status of your issue at: https://www.pivotaltracker.com/story/show/114881017.

[SocalNick]

Hi @youngm,

What sort of service takes sensitive information as parameters? The Services API - Provisioning doesn't indicate that parameters should be used to pass credentials or secrets. Credentials for a service should be passed back from the broker bind response.

Could you provide an example?

Thanks,

Nick

[youngm]

@SocalNick Though the spec doesn't say people should pass sensitive data as a service param the vast majority of our custom services do pass sensitive data to brokers.

Most use cases involve the concept of an "Existing" service plan that sits along side "Provisioned" plans. If an application being deployed has an existing set of credentials, which may be required for any number of reasons over a provisioned service, we allow these users to provide credentials to access this existing service. These Existing service instances are behaviorally indistinguishable from a provisioned service instance. This is important since many of our service have functionality beyond simply providing credentials, though getting credentials in a consistent format is also nice. For example, we have automated validation/testing and monitoring of these services as well as automated update of application dependencies in ServiceNow.

Another occasional use case involves a need for the broker to know who the user is that is creating the service. This can be necessary to, for example, validate that the current users is authorized to perform some action on an external system. In these cases the user provides an oauth token so the broker can validate that the creator is who they say they are.

Do those examples help?

[shalako]

@youngm is not alone on this. It is a very common use case for parameters to used for credentials or other sensitive data.

The generic use case of "binding services to services" is accomplished by passing credentials in parameters.

[SocalNick]

Thanks for the input @shalako. Let's make sure we use PRIVATE_DATA_HIDDEN for parameters for all audit events written for the following endpoints:

PUT /v2/service_instances/:service_instance_guid/routes/:route_guid POST /v2/service_instances/ PUT /v2/service_instances/:guid

POST /v2/service_bindings

POST /v2/service_keys

[petergtz]

Hi @youngm ,

We addressed your issue in this commit, and it will likely make its way into the next cf-release. If you have any additional concerns please let us know, otherwise feel free to close this issue.

Thanks, @petergtz and @wendorf, Cloud Foundry CAPI team

[youngm]

@petergtz Thanks!