[
https://issues.apache.org/jira/browse/CLOUDSTACK-6213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13963808#comment-13963808
]
Mandar Barve commented on CLOUDSTACK-6213:
------------------------------------------
Pilot patch uploaded on review board with following details.
Hi Alena,
I am attaching a pilot patch for the problem we are trying to solve. Please let
me know your thoughts, comments, suggestions on the approach and code. We can
make widespread code changes after agreeing on the approach and any other
details.
Problem: When stripping sensitive parameters from the response log string, the
strip logic should be generic. Current cleanString code strips few hardcoded
keywords from the response string.
Approach: As discussed in the context of CS JIRA 4406 I have modified
@Parameter annotation applied to fields of command classes and @Param
annotation applied to fields of response classes.
1. Annotations modified to add a new flag that conveys sensitivity of the
parameter for log, default set to false.
2. cleanString utility function is modified to process an array of strings
passed to it so it can strip all.
3. To keep this backward compatible (and also don't know the code change
implications at other places at this time) made sure old cleanString code will
continue to strip hardcoded keywords when zero sized filter array is passed.
This can change if we think so and when we think so. This change I am putting
is minimal focussed to solve current problem.
4. In ApiServer code where we are loading APICommand annotation to check if the
command response carried sensitive data, additional code is added to load
response class signature Param and SerializedName annotations to get the name
of the field that is flagged to carry sensitive information
5. A list of such names is built and passed to cleanString to strip
6. All code areas that got affected by cleanString signature change are
modified to pass zero sized filter arrays to cleanString
7. pom.xml is modified for server project to include gson dependency
8.StringUtil unit test code modified to use new signature for cleanString. (New
tests will need to be added in the final patch for testing the new functions of
cleanString)
On final note this addresses handling the audit logging of response strings
alone. I haven't looked into audit logging of request strings and what will
need to be done there.
This pilot patch is tested for listUsers command response. The code strips
apikey, secretkey and additional parameter userid (only meant for testing) as
they are tagged to be sensitive.
Thanks,
Mandar
> Add new field to API @Parameter indicating if the param should be skipped
> from logs
> -----------------------------------------------------------------------------------
>
> Key: CLOUDSTACK-6213
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6213
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Affects Versions: 4.4.0
> Reporter: Alena Prokharchyk
> Assignee: Mandar Barve
> Fix For: Future
>
>
> There are 2 parameters in @Apicommand:
> requestHasSensitiveInfo
> responseHasSensitiveInfo
> If set to true, the command will go through validation and certain parameters
> will be skipped from logging. Today these parameters are hardcoded. We have
> to introduce a generic way of marking this parameters as "excluded from
> logging". New field should be added to @Parameter for this purpose.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
