Proposal for Enhanced Handling of Sensitive Information in EventReport

[kahirokunn]

Background

Currently, when an EventReport resource is generated via an EventTrigger, all resources collected by the EventSource (for example, TLS Secrets) are stored in a base64-encoded format within spec.resources. As noted in the implementation comments:

If EventSource Spec.CollectResources is set to true, all matching resources will be collected and contained in the Resources field.

Setting collectResources to false, however, would disable many functionalities.

Issues

This implementation raises the following security concerns:

• Information Leakage in Audit Logs
  When the EventReport is recorded in the Kubernetes API Server’s audit logs, all resource data stored in spec.resources (even if base64-encoded, since the original data can be restored) may be output. This poses a risk of leaking sensitive Secret information.
  Note: In many Kubernetes-as-a-Service environments, it is challenging to modify the API Server’s audit settings, and from an RBAC perspective, this is not considered secure.

• RBAC Risks
  Embedding sensitive information in the EventReport resource creates a risk that the contents of Secrets, which should be access-restricted, might be inadvertently accessed by unauthorized users or components.

Proposal

We propose that, instead of embedding all resource data directly within the EventReport, a separate Secret resource should be created:

At the time of an event, the information of the resources to be collected (e.g., TLS Secrets) should not be included directly in the EventReport’s spec.resources. Instead, a dedicated Secret resource should be created within the cluster. The EventReport would then be modified to include reference information for that Secret (such as its name and namespace), or alternatively, retrieve a Secret bearing the same name as the EventReport.

Benefits

• Reduced Risk of Audit Log Leakage
  By segregating the data into a dedicated Secret resource, the API Server’s audit logs will no longer directly include sensitive information in base64-encoded form.
• Enhanced RBAC Management
  Since existing RBAC policies for Kubernetes Secrets can be applied to the separate Secret resource, access control can be enforced more rigorously.

Considerations & Cautions

• The implementation will require management of the new Secret resource (including lifecycle management and cleanup upon deletion, which can be achieved via OwnerReference).

Summary

This proposal calls for a modification of the EventReport specification to counteract the risk of sensitive information leakage—particularly Secret information—that arises during resource collection by the EventSource. By creating a separate Secret resource and including its reference in the EventReport instead of embedding data directly within spec.resources, we believe that the risks associated with audit logs and RBAC can be effectively mitigated.