LinkedIn
Twitter
1 ACCEPTED SOLUTION
Well first, what do you mean by "unauthorized"? The KVM is a protected resource and through RBAC there is no "unauthorized" changes allowed to the KVM. You may have a different definition of "unauthorized" than I do. Maybe you mean "unexpected" ?
In any case, there are a couple of approaches you might consider.
- First, you could examine administrative changes via the audit log. Every time an admin user - human user via the UI, or automated script via the API - changes a KVM, that action is audited. Apigee Edge keeps an audit log of all administrative changes, including changes to KVMs. It looks like this:
The audit log for an organization is readable via an API. And you can filter the audit records to examine only records that deal with KVM. A cron job or similar would be able to give you the ability to examine that audit trail every minute, every 10 minutes or whatever. I've seen people hook up that cron job to a Slack channel to get a notification in the channel when there is any administrative change. So this is one option for you.
But this audit log includes only administrative changes. as you probably know, it is possible for an API Proxy to include a KeyValueMapOperations policy in it, and that KVM policy can read or write the KVM. Any updates made by the policy will not be recorded in the administrative audit log. - You can read the KVM via the administrative API, and compare the contents with the desired state. Again you would be able to run this as a cron job, every minute, every 10 minutes, or on whatever interval you desire. This doesn't give you notice of WHO changed the KVM, but it does give you notice whether the change was made in a policy or via the administrative API. If you build in the smarts you could make it so that any diversion from the desired state is immediately rectified - you could update the KVM with the desired state when there is any delta.
One possible surprise here: the KVM reads done within policies are cached. Suppose you use the Administrative API to set the KVM value back to desired state. If you do that, the KVM cache within the message processor is not reset. The newly-written value will become visible in the policy only after the time-to-live on the KVM cache expires. This cache is specified in the policy configuration itself. The caching behavior van be surprising to some people, but this is as designed.
Helpful?
Well first, what do you mean by "unauthorized"? The KVM is a protected resource and through RBAC there is no "unauthorized" changes allowed to the KVM. You may have a different definition of "unauthorized" than I do. Maybe you mean "unexpected" ?
In any case, there are a couple of approaches you might consider.
- First, you could examine administrative changes via the audit log. Every time an admin user - human user via the UI, or automated script via the API - changes a KVM, that action is audited. Apigee Edge keeps an audit log of all administrative changes, including changes to KVMs. It looks like this:
The audit log for an organization is readable via an API. And you can filter the audit records to examine only records that deal with KVM. A cron job or similar would be able to give you the ability to examine that audit trail every minute, every 10 minutes or whatever. I've seen people hook up that cron job to a Slack channel to get a notification in the channel when there is any administrative change. So this is one option for you.
But this audit log includes only administrative changes. as you probably know, it is possible for an API Proxy to include a KeyValueMapOperations policy in it, and that KVM policy can read or write the KVM. Any updates made by the policy will not be recorded in the administrative audit log. - You can read the KVM via the administrative API, and compare the contents with the desired state. Again you would be able to run this as a cron job, every minute, every 10 minutes, or on whatever interval you desire. This doesn't give you notice of WHO changed the KVM, but it does give you notice whether the change was made in a policy or via the administrative API. If you build in the smarts you could make it so that any diversion from the desired state is immediately rectified - you could update the KVM with the desired state when there is any delta.
One possible surprise here: the KVM reads done within policies are cached. Suppose you use the Administrative API to set the KVM value back to desired state. If you do that, the KVM cache within the message processor is not reset. The newly-written value will become visible in the policy only after the time-to-live on the KVM cache expires. This cache is specified in the policy configuration itself. The caching behavior van be surprising to some people, but this is as designed.
Helpful?
