Enhancement: Suppress Secret data in logs

[suin]

Background

KCL Operator's default MutatingWebhookConfiguration targets Pod and Deployment resources, which is a sensible default that should remain unchanged. However, users may choose to extend the webhook configuration to include Secret resources, leveraging KCL's powerful validation and mutation capabilities for their specific use cases.

I'm currently working on a project where we need to securely mutate Secrets using KCL Operator. We've configured our own MutatingWebhookConfiguration to include Secrets because KCL's validation and mutation capabilities are exactly what we need for our Secret management requirements. This real-world use case highlighted the need for more secure logging when handling Secrets.

Problem

The current logging behavior poses a security risk when users configure Secret mutation:

v.Logger.Infof("Decode Mutate object.. %v", out.String())

This logs the entire object content, including sensitive data from Secret resources. While this logging is helpful for the default Pod and Deployment mutations, it becomes a security concern when users extend mutation to Secret resources.

Impact

• Security risk: When users configure Secret mutation, sensitive data gets exposed in logs
• Limited security: Users who want to extend KCL's features to Secret management need additional security measures
• Compliance issues: Even with explicit configuration, the current logging behavior might prevent Secret mutation use in security-conscious environments

Proposed Solution

Add Secret-aware logging that suppresses sensitive content:

if unstructuredObj.GetKind() != "Secret" {
    v.Logger.Infof("Decode Mutate object.. %v", out.String())
} else {
    v.Logger.Infof("Decode Mutate object.. (output suppressed for Secret)")
}

This change ensures secure handling of Secrets when users explicitly choose to include them in their webhook configuration, while maintaining the current behavior for default resources.

Benefits

1. Security: Safer handling when users choose to mutate Secrets
2. Flexibility: Users can safely extend mutation to Secrets if needed
3. Default Unchanged: Maintains current default behavior for Pod and Deployment
4. Debugging: Keeps useful logs for non-Secret resources

Real-world Impact

In our project, this enhancement would allow us to:

• Safely use KCL's powerful features for Secret management
• Meet security compliance requirements
• Maintain audit trails without exposing sensitive data
• Continue using KCL Operator's excellent mutation capabilities for all our resources

Future Considerations

1. Add documentation about secure practices when extending webhook configuration
2. Consider adding secure logging patterns for other potentially sensitive resources
3. Consider adding log level configuration for different resource kinds

Alternative Approaches

1. Add explicit configuration for logging behavior

   • Pro: More flexible for different use cases
   • Con: More complex, might lead to misconfiguration

2. Add warnings when Secret resources are detected

   • Pro: Helps users understand security implications
   • Con: Doesn't solve the core security issue

The proposed solution provides a secure foundation for users who choose to extend mutation to Secret resources, while maintaining simplicity and current defaults.

Contribution

I'm happy to contribute a pull request implementing this solution if the approach is approved. The implementation would focus on enhancing security for user-configured Secret mutations while maintaining the current default behavior.