Before we test decryption, we’ll need to be sure that the events from Cribl LogStream are indeed being encrypted. A simple search suggests that things are looking good with crypto_group_0 and crypto_group_1 both being encrypted, each with a different key.
As a quick test, we can assign the roles we created to the Splunk admin user. This will allow the Splunk administrator to decrypt all data encrypted by Cribl LogStream
As you can see below, issuing the | decrypt command has had the desired effect – All data in groups 1 and 2 is now visible to the Administrator.
Dialing It In
Lets create a user that has decrypt permissions on crypto_group_0 but nothing else. We do this by adding the crypto_group_0 role to the user.
Now let’s issue the same search that we did as Administrator and confirm the results. As you can see, this user has decrypted the part of the event permitted by their role, but has not decrypted the data in crypto_group_1.
Testing it the other way around, let’s create another user with access to crypto_group_1 but not crypto_group_0.
That seems to have worked out perfectly, as with the previous user, this user can only see the data that they are permitted to decrypt by the role that they’ve been assigned.
And there it is, how to dynamically encrypt individual fields of an event with unique keys before they are even indexed. One of those rare use cases that displays the flexibility and strength of integration between two first-class products, while still requiring some “fancy footwork” and lateral thinking.