- Newest
- Most votes
- Most comments
IAM permissions don't consider the data contents of the target resources, so there's no way to use IAM to restrict access to CloudWatch log entries based on their contents.
This is roughly equivalent between CloudWatch Logs and DynamoDB. In Dynamo, you can't restrict access based on the data contained in items being read or written. You can only control which attributes (loosely equivalent to columns in a table) can be specified in a request. Similarly in CloudWatch Logs, with a different data structure, you can control which log streams in which log groups can be accessed but not which data the log entries are allowed to contain.
In theory, you could fulfil your requirements by building a background processing mechanism to ingest log data from the "full" log groups/streams, then filter and/or mask it, and write the redacted/masked version of the data to a second log group. Different users could then be granted access either to the "full" and "masked" log group.
You could also choose to send the processed data to S3 buckets, instead of another CloudWatch log group, and possibly also use the built-in ability to have CW Logs export data to S3 (https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html) as a building block for your filtering automation. However, both these options would involve setting up a custom solution to pre-process the data, even if the solution would run on AWS services.
Relevant content
- AWS OFFICIALUpdated 2 years ago
