Move data from encrypted KVM store between orgs and env

Not applicable

hi,

Ours is HIPAA complaint apigee public cloud. Hence as per recent apigee communique, all the KVMs have been migrated to the encrypted KVM from the unencrypted KVM.

To port the data between env/orgs, I have tried the grunt plugin and the management APIs, but KVM data response from either of these options seems to be *****. Hence I am facing challenge in automoving KVM config across environments and orgs. Any pointers would be of great help.

Thanks,

Karthikeyan

1 2 697
2 REPLIES 2

If you are experiencing a problem, seeing ***** and not the actual content, then I suspect it is a problem with your expectations and assumptions, and not with the grunt plugin itself.

As you probably know, the administrative APIs for Apigee Edge allow you to perform CRUD (Create, read, update, delete) operations on Key-Value Maps. This is what the grunt plugin is built on, and this is what apigeetool is built on, what the Powershell Module is built on.... Every client-side administrative tool that fiddles with KVMs depends on the same administrative APIs.

For un-encrypted KVM, the admin API will deliver actual content from the KVM when you query. If you store key1=value1, then you will see that upon query. For encrypted KVM, the admin API will deliver '*****' as the content when you query. If you store key1=value1, then when you retrieve it you will see key1=***** . This is as designed.

Migrating data from an unencrypted KVM store into an encrypted KVM store will be easily possible. Migrating data from an encrypted store to any other store is not possible, because there is no way to administratively read the values that have been stored in an encrypted KVM store.


I think what you are trying to do is administratively extract data from the encrypted KVM. You cannot do that with the grunt plugin. And, because every client-side administrative tool depends on the same administrative APIs, they will all behave the same way - in the way I have described above - with respect to reading and writing encrypted and unencrypted KVMs.


By the way, on the topic of "migrating data" - we would recommend that you do not use Apigee Edge itself as the system of record. Instead, the data ought to be stored in a source code control system. Eventually it finds its way into a filesystem, and the provisioning of the KVM is done via an automated system built on the APIs I have just described. A bash script, or a nodejs script, or a Go program, or a powershell script, etc. Following this pattern you never migrate from one KVM to another. Instead you just point your provisioning script to a different organization, and set a simple flag to tell it to provision the new KVM as encrypted.

if you *must* extract encrypted data via an API you can create a proxy with the KVM policy to read the encrypted data and use that in the response for the proxy.

For example, via the management APIs:

GET /v1/o/<ORG>/e/test/keyvaluemaps/vault/entries/password
{
  "name" : "password",
  "value" : "*****"
}

I believe that is what you are seeing right now.

If you create a simple proxy to read from the map, with a KVM policy as such:

<KeyValueMapOperations async="false" continueOnError="false" enabled="true" name="Get-KVM-Entry" mapIdentifier="vault">
    <DisplayName>Get KVM Entry</DisplayName>
    <Properties/>
    <ExclusiveCache>false</ExclusiveCache>
    <ExpiryTimeInSecs>300</ExpiryTimeInSecs>
    <Get assignTo="private.value" index="1">
        <Key>
            <Parameter ref="key"/>
        </Key>
    </Get>
    <Scope>environment</Scope>
</KeyValueMapOperations>

Where, {key} comes from the path for example,

 /v1/kvm/{map}/entries/{key}

Then you can build your own response in an AssignMessage policy:

<AssignMessage async="false" continueOnError="false" enabled="true" name="Assign-Response">
    <DisplayName>Assign Response</DisplayName>
    <Properties/>
    <Set>
        <Payload contentType="application/json">{
    "name": "{key}",
    "value" : "{private.value}"
}</Payload>
    </Set>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</AssignMessage>

And invoking such API would result in:

GET <ORG>/v1/kvm/vault/entries/password
{
    "name": "password",
    "value" : "Key12345"
}

As Dino pointed, you should have the same KVM data also stored elsewhere and in that case you wouldn't need to do this, but as I started, if you have no other way and you must do it, this would be one way.

Cheers,

Ricardo