Since we are capturing traffic from our service, we can observe individual request data in the traffic viewer. When we drill down into requests, we can see that we are capturing some sensitive information such as an API key in the authorization header for a request to a third party.
Although we can manipulate this during a replay using transforms, we may not want to ever capture this data or let it leave the cluster. This is where Data Loss Prevention comes in. We can configure the Operator to redact this data.
Configure Data Loss Prevention
Navigate to the DLP config section and select the standard config. Here you can see that the standard config comes with a default set of fields to redact such as
jwt and so on. If you want to make a custom config, you can create your own.
Enable Data Loss Prevention
DLP is not enabled by default so you must configure it during or after installation. If you have installed via the Helm chart, you can see the corresponding values that need to be edited here:
# Data Loss Prevention settings.
# Instructs operator to enable data loss prevention features
# Configuration for data loss prevention
enabled: true and put in whichever config you want to use in the
config field. If you installed the Operator via
speedctl, you have to edit the
speedscale-operator configmap in the
speedscale namespace with
kubectl -n speedscale edit cm speedscale-operator.
Edit the fields
DLP_CONFIG to the desired values and then make sure to restart the Operator in order for it to pick up on the new settings. This can be done via
kubectl -n speedscale delete pod -l app=speedscale-operator.
After making this change, we can see for the same request that the field has been redacted. This happens at the Operator level and not in our cloud sytem so the
Authorization header value never left your cluster and was never seen by Speedscale.