In this short post we will talk about the implementational difference between Apigee Edge (SaaS offering in the public cloud) and Apigee X or Apigee hybrid with regard to managing the contents of Apigee Key Value Maps (KVMs).
Whilst most of the paradigms and interfaces for how to implement API proxies remain unchanged between Apigee Edge and Apigee X and hybrid, there are (as of the writing of this post) a few architectural differences that require a slightly different way of thinking. Most notably to highlight here:
- KVM contents are no longer managed via the Apigee API. Read below for how to manage KVM contents from within the API runtime plane.
- Hosted targets are no longer supported but can be easily migrated to Cloud Run as described in a previous blog post.
- Edge extensions are not supported. Some common scenarios are covered by reusable shared flows that are available as open source community assets in Apigee DevRel
Why are KVMs handled differently in Apigee Edge vs. Apigee hybrid and Apigee X?
The difference in how KVM content is handled comes down to a few factors. In Apigee Edge the KVMs are managed in a true multi-tenant fashion. The authorization and the optional encryption of the content is handled transparently by Google. In Apigee X and hybrid the KVMs are kept at the runtime level. This means that the customer is in control of the encryption and the content. Because of that, all operations on the KVM’s content need to be performed from within the runtime itself.
As a consequence of this, the previous Management API functionality to manage KVM entries no longer apply to Apigee X or hybrid. The KVMs in Apigee X or hybrid still need to be created via the management API or the Apigee UI but their content can only be created, read or deleted from within the runtime from a KeyValueMapOperations policy.
Operating KVM entries via a custom API Proxy
Assuming you already created a KVM via either the Apigee API or the UI, you can edit its content using the KeyValueMapOperations policy. If you have used this policy before you might remember the mapIdentifier attribute of the root element of this policy that is used to statically define the name of the KeyValueMap that the policy operates on. You can still use this attribute to create dedicated API proxies for each KVM you wish to manage entries in. If you have several KVMs that need this functionality then adding proxies with static KVM names for each one of them will quickly become impractical.Luckily, Apigee X as well as Apigee hybrid from version 1.4 onwards added the option to use dynamic KVM names in the KeyValueMapOperations policy in the form of the MapName element. This allows you to obtain the name of the KVM from the incoming request and use it in the KVM operations policy. For a restful URI the kvm name could be read into a flow variable called kvm.name using an ExtractVariables policy as follows:
<ExtractVariables name="EV-PathParameters">
<URIPath>
<Pattern ignoreCase="true">/kvms/{kvm.name}/entries/{kvm-entry.key}</Pattern>
<Pattern ignoreCase="true">/kvms/{kvm.name}/entries</Pattern>
</URIPath>
</ExtractVariables>
A full example of an implementation of the GET, POST and DELETE methods for KVMs with a dynamic name can be found in the Apigee DevRel Github repository.
Operational considerations
As briefly mentioned before, KVMs have to be created before their name can be used in the MapName element. Depending on the automation requirement, the KVMs could also be automatically created by calling the Apigee API from within the Apigee proxy. For most use cases creating the KVMs would still be done as part of the configuration automation.
A second important aspect then it comes to operating a KVM admin proxy is authentication and authorization. As KVMs often contain important configuration, it is important that only authorized users can modify its content. Users are therefore strongly advised to enforce additional security policies e.g. via OAuth2 on the KVM admin API proxy before making it available.
Contributors
58 People are following this .
