Open Alex-Klein opened 3 years ago
Extract common parameters that are safe from request bodies and add them to the audit log.
@russjones what do you mean by: "common parameters that are safe"?
@Alex-Klein
Kubernetes API allows the following content-types:
application/json
application/yaml
application/vnd.kubernetes.protobuf
It's possible to send JSON content in the request body and receive protobuf and the opposite depending on Accept
and Content-Type
headers.
Since protobuf is a binary format, do you need the request and response bodies to be in a readable format?
What
When users use the kubernetes integration and perform actions with kubectl, only the “header” data is being logged, e.g. that e certain endpoint of the Kube-API was accessed, timestamp and HTTP method but no payload. For compliance reasons, we need to store / keep the actual content of the transaction in an auditable format.
Take the following comparison: We see only that user X has made a POST/PUT request to the API endpoint for namespaces; we need to know the content of it, for instance that metadata a new namespace with name ‘xyz’ has been created.
How
Log payload (request and response) of interactions to the Kube API. Some mechanism has to be found when very large payload is being transmitted.
Why
Our corporate compliance and legal regulation for certain customers requires a session recording for all types of access. For instance, bank customers need replayable details of what modification has been carried out on their environment.
Workaround
Using kubectl on a teleport node which gets accessed by tsh ssh. But in this case no real RBAC can be achieved.