Encrypted KVM entries are being shown in trace

Not applicable

We're using encrypted KVM to retrieve security credentials for fetching access token from a 3rd party provider and using ServiceCalloutPolicy to make the call.

While checking the trace I found these credentials are printed and shown in plain text under "ServiceCallout.request" property.

All the variables used for retrieving the entries from encrypted KVM, are prefixed with "private." so that APIGEE doesn't print the same in trace (as claimed). But still all these private and secured info are being shown in plain text in trace.

Please suggest if this is a known issue or if any workaround is there.

Note: We're using APIGEE on-premise private installation and version is 4.17.01

0 12 1,298
12 REPLIES 12

@Dipankar Aich ,

Can you please provide more details of the KVM operations policy and ServiceCallout policy. Also please let me know if you are able to see values of KVM using edge UI?

Thanks,

Santosh

Yes, your question is clear enough, as far as it goes. And it sounds like a bug. But when you say "these credentials are printed"... I'm not clear.

Can you provide the configuration for the ServiceCallout? How do the private. variables get inserted as credentials into the request?

Also if you could attach a screenshot of the Trace UI, showing where and how the credentials are displayed, but with the appropriate information smeared out, that would be helpful.

Hi,

The private entries from kvm are displayed when used in request body of service callout or when using print statement and not displayed elsewhere.

Not sure if it is a bug or expected behaviour(as only private.variable are hidden, and here it is assigned to different flow variable - ServiceCallout.request in this scenario).

5571-screen-shot-2017-09-01-at-121348-pm.png

Not applicable

servicecallouttrace.pngThanks @santosh_ghalsasi, @Dino & @Rohan, for your response.

Here is the sample of the KVM and ServiceCallout policies which I've configured.

<KeyValueMapOperations async="false" continueOnError="false" enabled="true" name="KeyValueMapOperations.Credentials" mapIdentifier="sfdc_creds"

<DisplayName>KeyValueMapOperations.Credentials</DisplayName>

<ExclusiveCache>false</ExclusiveCache>

<ExpiryTimeInSecs>300</ExpiryTimeInSecs>

<Get assignTo="private.username">

<Key>

<Parameter>username</Parameter>

</Key>

</Get>

<Get assignTo="private.password">

<Key>

<Parameter>password</Parameter>

</Key>

</Get>

<Scope>environment</Scope>

</KeyValueMapOperations>

<ServiceCallout async="false" continueOnError="false" enabled="true" name="ServiceCalloutRetrieveToken">

<DisplayName>ServiceCallout.RetrieveToken</DisplayName>

<Request clearPayload="true" variable="myRequest">

<IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>

<Set>

<Verb>POST</Verb>

<FormParams>

<FormParam name="username">{private.username}</FormParam>

<FormParam name="password">{private.password}</FormParam>

</FormParams>

<Headers>

<Header name="Content-Type">application/x-www-form-urlencoded</Header>

</Headers>

</Set>

</Request>

...........

</ServiceCallout>

Please refer to the attachment to see how these private variables are printed in trace as part of ServiceCallout.request property


Not applicable

Hi Dipankar,

I think this is more similar to your debug feature which you use in Java/.Net world. Even there, if some data has to be retrieved from an encrypted store and if that has to be passed in an un-encrypted manner while calling another service you will be able to see their values(in debug mode) in plain text right. The trace feature is similar to that.

The claim of Apigee not leaving any trace/logs of encrypted KVM's is in the logs. As you would agree we wont do debugging directly in production environments. The Trace is simply to assist developer to debug during API development and hence encrypted KVM will be seen as plain text in Trace mode.

Hope it clears your question. Please do let us know if you need further help.

Thanks

Prakash

Hi jpprakash,

If you are saying that this behaviour is 'by design' then the documentation here seems to be misleading:

http://docs.apigee.com/api-services/content/key-value-maps#aboutencrypted

Specifically, it says:

Trace and debug

When you use the Key Value Map Operations policy to retrieve encrypted KVM values, you supply the name of a variable to store the value. To get an encrypted value, you need to add the "private." prefix to the variable name, which prevents the KVM keys/values from appearing in Trace and debug sessions

I have mis-understood the question. The question is actually how to mask the username and password (encrypted KVM) from subsequently being visible in ServiceCallout.request

Apologies for my incorrect answer there


solution for you is to add the prefix "private." to the variable names that you plan to store in the encrypted KVM.

See here for an example. https://community.apigee.com/questions/41098/with-a-keyvaluemapoperations-policy-variables-set.html Full Reference here http://docs.apigee.com/release-notes/content/160921-apigee-edge-public-cloud-release-notes#newfeatur...

Hi Nicola,

My understanding is that the problem is how to mask the values of username and password (encrypted KVM) from subsequently being visible in ServiceCallout.request.

There is a similar question here: https://community.apigee.com/questions/8933/how-to-data-mask-servicecalloutrequest-elements.html

I'm not clear if the a DataMaskConfiguration (as described here: http://docs.apigee.com/api-services/content/data-masking) would work in this scenario?

Hi Rohan, if you assign the resulting variables from the lookup from the encrypted KVM into 2 flow variables also with a "private." prefix, then they will also not shown in the trace.

@Nicola

Yes, all data assigned to private.{{variable}} is hidden(not masked) from the trace.
Here, in the scenario mentioned.. The private variable is assigned as a part of the service callout request body(which is not a private variable) making it visible in the trace.

Refer this for masking specific data in trace and debug sessions.