Implement Audit Logging platform service

[reshnm]

Understand the Task

Audit Logging in this context refers to audit logs that are written by a Kubernetes API server and are being pushed into an Audit Logging backend.

In this context Autid Log events are containing access operations to the Kubernetes API (e.g. CREATE, UPDATE, DELETE ...)

The configuration of the Kubernetes API server regarding Audit Logging depends on the type of cluster provider.
This means that for each type of cluster provider, there needs to be a specific implementation of a audit log platform service, e.g.:

• platform-service-auditlogging-gardener

Note: for the Kind cluster provider it doesn't make sense to have audit logging since it is only used for testing and development purposes.

A audit logging platform service would work like this:

1. Watch Cluster resources for a matching type (e.g. Gardener)
2. Filter for cluster purpose (e.g. only platform, workload, but not mcp)
3. For each Cluster configure the audit logging based on a service specific provider configuration

Open questions

• Is it a problem when a audit logging service is modifying the cluster configuration that is managed by a cluster provider? Would these changes regarding the audit logging get lost when it is being reconciled by the cluster provider?

Things that should not be solved

• A audit logging platform service shall not provider a audit logging service for MCP users. This has to be solved differently.

Any further valuable resources.

No response

What is required to accept the Task as done.

Done Criteria

• ...
• Code has been reviewed by other team members
• Internal technical Documentation created/updated
• New / changed code is documented
• Unit Tests created for new code or existing Unit Tests updated
• Integration Test Suite updated
• Enduser Documentation updated (if applicable)
• Successful demonstration in Review

[GenosseOtt]

moved this one back to validation - @reshnm - lets get the Why and what in this issue please :-)

[In-Ko]

as discussed yesterday, I have assigned Rene to provide some more tech infos on this task. I believe we once said that this is rather relevant for our V2 architecture to go out, so we should get some more details here in order to be able to refine it.

[reshnm]

Added tech advice

[reshnm]

@Diaphteiros can you have a look at the open question and see wether this would work or if we need a different approach?

[Diaphteiros]

It could work, I'm not completely sure though.

The Gardener ClusterProvider overwrites changes to the shoot in general. However, since the Gardener itself adds some fields that are usually not set by the customer - e.g. the seed name - which are not allowed to be deleted again, the controller actually 'merges' its desired configuration into the existing shoot manifest. This merge operation should only overwrite fields that are actually defined in the shoot template that is given to the ClusterProvider and it should keep fields that are not defined in there as they were before.

This means that in theory it would be possible to inject auditlog configuration into a shoot that is managed by the ClusterProvider, as long as this configuration does not clash with any field in the shoot template or any field that gets 'special treatment' by the ClusterProvider.

We need to test this assumption, though.