The Pure1 audit log explained (a bit)
In the early days of my learning curve on Pure arrays, I see a lot of consistencies between Pure and the other vendors I’ve worked with. For example an (EMC) LUN or volume is called a (Pure) volume, but hey! Everybody understands me when I simply say “LUN”. Then you have host groups, aka clusters, hosts, LUN addresses, bandwidth, throughput. If you know these names from one vendor, you speak the “storage” language.
Logging is no different: when an administrator creates a (LUN or) a volume on a Pure system, you can easily see that in the audit log in Pure1, but from time to time you will also see entries from root users popping up in the audit trail:
But where is this suddenly appearing root user coming from and what is its purpose? And more importantly: can it do any harm? Can this root user be taken hostage or hacked? Or is this user actually a hacker?
In the left column (I wiped out the system names in my short example) you will see the names of the Pure arrays on which actions were performed. In the 2nd column the user is displayed (in my example some “admin” user created some volumes). But here it is:
I’m also seeing a root user!
Who is this root user? After some serious testing on both arrays, I came to the conclusion that any local action performed by myself which needs some sort of configuration on the other array, this action is performed by the local array itself. When the link was set up between the two arrays, permissions were granted to both arrays to create or adjust the necessary required items on the remote array. A good example is when a volume is placed in a POD which will be stretched later or when a new LUN is created inside a POD, so it will be accessible on both the local array as well as the remote array, the local array itself will create the volume on the remote array as soon as the local LUN is placed in the stretched POD and it will use the root user account to do so. I’ve tested this several times on both arrays and it was conclusive: the root user was me, myself and I!!
So stop searching for that root user, since it’s not really there. Well, it is not visible as a user anyway. It is actually the system’s backdoor to allow other arrays perform the necessary configurations.
So locally you’ll see your own account in the logging, but on the remote array, whenever your local action requires a remote action, the remote action will be performed by the “root” user.
I must admit that at first this scared the sh*t out of me, especially considering the current threat of hackers, zero day threats, ransomware and high sums of money required to gain access to your data again after being held hostage, but I can assure you that this is a result of a “works as designed” procedure.
0 Comments.