As a manage service provider, I would like to know:
- what actions have been performed on an Application instance
- who has performed those actions
- when were the actions performed
One way to implement this will be to capture this information via the mutating-webhook component of KubePlus. The mutating-webhook intercepts all the incoming actions. So it provides natural place to implement this functionality. Where should this information be stored? One option is to store it inside the mutating webhook. A problem with this approach is we then have to build some functionality to expose this information for outside consumption. Also, for durability purpose, we will have to periodically save this information in some persistent storage. Another option is to save this information as an annotation on the application object itself. This will obviate the need for additional mechanism for external consumption of this information, and also for periodically saving it for durability. The main concern here will be the size of the object will increase overtime. A third option will be to create a "audit configmap" and store the information in the configmap. This option has the advantage that it does not make the application object itself bloated, and also gains from the underlying storage (etcd) available in the cluster. The name of the configmap can be saved as an annotation on the application instance.
We should go with the third option above. In order to make the audit information available to the users, we can implement the following kubectl plugin:
kubectl audit <Instance name>
This plugin will find out the config map from the provided instance. Then read the configmap and display the audit information available there.
As a manage service provider, I would like to know:
One way to implement this will be to capture this information via the mutating-webhook component of KubePlus. The mutating-webhook intercepts all the incoming actions. So it provides natural place to implement this functionality. Where should this information be stored? One option is to store it inside the mutating webhook. A problem with this approach is we then have to build some functionality to expose this information for outside consumption. Also, for durability purpose, we will have to periodically save this information in some persistent storage. Another option is to save this information as an annotation on the application object itself. This will obviate the need for additional mechanism for external consumption of this information, and also for periodically saving it for durability. The main concern here will be the size of the object will increase overtime. A third option will be to create a "audit configmap" and store the information in the configmap. This option has the advantage that it does not make the application object itself bloated, and also gains from the underlying storage (etcd) available in the cluster. The name of the configmap can be saved as an annotation on the application instance.
We should go with the third option above. In order to make the audit information available to the users, we can implement the following kubectl plugin:
kubectl audit
<Instance name>This plugin will find out the config map from the provided instance. Then read the configmap and display the audit information available there.