Creating KVM entries in Apigee X

[marc]

I have a situation where I need to route to a different target server depending on a client variable. Each server needs to have a unique bearer token passed along with the request payload. From the documentation it seems that using KVMs would be good for this scenario. However, I am finding it troublesome to create KVM entries so that they can be stored and available at runtime while in Apigee X.  I understand that KVM entries are handled differently in Apigee X than in Edge, however, I can't seem to find out how to create a KVM entry that is available at runtime. Can someone point me in the direction of best practice to store secrets that need to be available at the Apigee X runtime? Thank you

[davorm]

Hi,

you can find explanation and solution here

Regards

[marc]

So I seem to be able to move forward by setting the initial values that I want to store in the KVM through a policy that I implement at runtime. This seems redundant as it would appear to store the initial entries every time the policy runs which is every time the proxy executes. But it is the only way I can seem to create entries in Apigee X as I am unable to achieve this through the console nor the API. Is this the only way to store KVM values in Apigee X? Assuming I'll need to store a few thousand values, what are the performance issues I can expect doing this every time a proxy is executed ?

<KeyValueMapOperations continueOnError="false" enabled="true" name="KVM-Set-And-Get" mapIdentifier="KVM-pw-store2">
  <DisplayName>KVM-Set-And-Get-PW</DisplayName>
  <Properties/>
  <ExclusiveCache>false</ExclusiveCache>
  <ExpiryTimeInSecs>300</ExpiryTimeInSecs>
  <InitialEntries>
    <Entry>
      <Key>
        <Parameter>server1-password</Parameter>
      </Key>
      <Value>123456</Value>
    </Entry>
    <Entry>
      <Key>
        <Parameter>server2-password</Parameter>
      </Key>
      <Value>password</Value>
    </Entry>
    <Entry>
      <Key>
        <Parameter>server3-password</Parameter>
      </Key>
      <Value>hunter2</Value>
    </Entry>
    <Entry>
      <Key>
        <Parameter>server4-password</Parameter>
      </Key>
      <Value>hunter3</Value>
    </Entry>
    <Entry>
      <Key>
        <Parameter>server4-password</Parameter>
      </Key>
      <Value>hunter4</Value>
    </Entry>

  </InitialEntries>
  <Get assignTo="secret-password">
    <Key>
      <!-- get the pw.key variable a custom attribute that comes in with the api key -->
      <Parameter ref="pw.key"/>
    </Key>
  </Get>
  <Scope>environment</Scope>
</KeyValueMapOperations>

[dchiesa1 · Accepted solution]

There is an outstanding feature request to allow manipulation of the KVM via the administrative API.

In the meantime, there is a way you can do it, using your own API proxy.

It is here: https://github.com/apigee/devrel/tree/main/references/kvm-admin-api

Deploy it once, then you can invoke it to insert things into the KVM. Remove your InitialEntries from the KVM Get policy. 

The way with InitialEntries also works, but in my opinion  it's less secure and generally less simpatico. That is the kind of information that should probably not be in the KVM policy configuration.

Does this help?

This seems redundant as it would appear to store the initial entries every time the policy runs which is every time the proxy executes.

I believe that is not correct. The InitialEntries get stored if and only if the KVM does not have those entries. Even so I don't like the idea of using InitialEntries for this kind of case. It does have it's purposes. But this is not one of them.

[marc]

Thanks Dino. Prior to seeing your reply I realized that after the proxy had run once I could remove the initial entries from the KVM policy and the values were still accessible. Another alternative was to create a temporary proxy in the console, run it with the KVM policy to seed the initial entries in the KVM store and then delete it. The values were accessible to whatever the scope of the KVM policy was. 

[dchiesa1]

YES, that works too!  I'm glad you were able to find a workaround to this limitation.