As a VMware administrator the security of your environment is a big concern. Password security can be a challenge when you have to provide access to your secure environment to the Splunk Solutions Administrator who needs to monitor the environment using Splunk for VMware. We have implemented RC4 password obfuscation to provide security in the Solution. While security and password obfuscation is important, you can use the still use clear text password storage. As the Splunkadmin user, use
credentials.pl to obfuscate passwords for your
Important : Remember that the
engine.conf file contains the configuration used ONLY by the Splunk FA VM to send data from the VMware environment to your Splunk indexers.
By default, passwords with potentially large permission sets are stored in clear text in the configuration file,
engine.conf. As a Solutions administrator managing the Splunk for VMware solution you need access to the VMware environment but you may not have privileges to access the passwords to accounts in the VMware infrastructure. With password obfuscation the VMware administrator can secure passwords and allow you to have access you need.
We have also enable you to create credentials storage. As a Solutions administrator you can give the credentials tool to the VMware administrator to generate an encrypted credential storage file and return it to you. You can then use this to access the VMware resources being managed by Splunk for VMware.
Passwords are encrypted using a different key based on the stanza type. How the key is generated does not impose any limitations on what you as the Solutions administrator can do. For example, you can manually change the contents of a list stanza without having to use the credential manager tool.
How the keys are generated:
- For the default stanza, the key is a set value.
- For a single entry stanza, the key is based on the hostname.
- For a regex stanza, the key is based on the Regex entry.
- For list stanzas, the key is a set value.
To learn more about the
credentials.pl tool, see About credentials in this manual.
Things to note about passwords
- Passwords in
credentials.confare presumed to be encrypted. An unencrypted password in
credentials.confwill fail to be applied correctly.
- You can specify passwords in
engine.confbut note that they are overridden by the entry you specify in
credentials.confif the host matches a
credentials.confentry. This means that if the correct credentials are in
engine.confand the crecentials are incorrect in
credentials.conffor the same host, the
credentials.confcredentials will always be applied and never work.
- If you specify passwords in
engine.confyou must do so in clear-text.
Creating credentials for larger environments
As the VMware systems administrator, for larger deployments you can create credentials in
credentials.conf using a regex stanza or a list stanza, in addition to using the default and single entry stanzas for smaller environments .
Use a regular expression to determine host credentials
Use a regular expression to determine the credentials that are valid for particular hosts based on a defined pattern. If the host's hostname matches the pattern in the regex entry, then it uses the credentials from the regex entry. A regex entry is denoted by the surrounding slashes in the host field. For example:
host=/^esx.*/ username=foo password=bar
In the example above, the regex will match any host having a hostname starting with esx. The only other requirement is that the host must have the credentials foo/bar. Using Regular expressions to define credentials is particularly useful when a client has an environment with a large number of hosts and the hosts are named according to a defined pattern.
Use a list entry to determine host credentials
The list entry is a special case of the regex entry. List entries are denoted by a trailing | character and consist of unique hostnames delimited by | characters.
Important: If the hostname is a partial match on one of the | delimited names it will be considered a full match. Also, unlike regex entries, list entries have a standard key encryption. This means that list entries can be edited inline without re-encrypting the password. For example
/esx1|esx2|esx3|/ will match the same hosts but will encrypt the passwords differently. If you use the former syntax you may easily append another host, such as
esx1|esx2|esx3|esx4| without ever changing the encrypted password and it will still work. This allows for small modifications to the credentials file without having to decrypt and recrypt the whole file. Here is an example list entry:
[list1] host=esx1|esx2|esx3| username=foo password=bar