It is possible to store credentials in an external PAM (Privileged Access Management) environment and have the GLU.Engines collect the credentials at the time of start up.

Integration to the following PAM systems are supported

• AWS secrets
• Azure Key Vault
• HashiCorp Vault

Please contact GLU Support for the details on how to configure the each PAM system in the start up scripts.

Connectors Secure Credential Storage

In the connector environment settings, the Vault option allows you to securely store and manage sensitive information such as usernames and passwords. Here is how you can use the Vault flags for each field:

Connectors Secure Username Vault Flag

1. Purpose: When enabled, this flag ensures that the username for the database connection is securely stored and retrieved from a VAULT, rather than being entered manually and stored in a potentially insecure manner.

2. How to Enable:

• Toggle the Vault switch next to the username field to “ON”.

• The VAULT secret-name that holds the username will be presented in the build manager once the GLU.Engine is built. If the secret is stored in the configured VAULT it will be picked up and used by the GLU.Engine.

• Once enabled, the username will be dynamically retrieved from the VAULT at the point the GLU.Engine is run and used in the execution of the connection process.

Connectors Secure Password Vault Flag

1. Purpose: Similar to the username, this flag secures the storage of the password used for the database connection.

2. How to Enable:

• Toggle the Vault switch next to the password field to “ON”.

• Enter the VAULT secret name for the password in the password field. Ensure this secret is already present in the VAULT.

• The password will be used from VAULT when needed for authentication.

Secure Storage of SSL Credentials using Vault

The Vault flags in the connector environment settings facilitate the secure management of SSL credentials by storing these sensitive details in VAULT. Here’s how to configure each section:

Connectors Secure Key Store

1. Purpose: The Key Store contains private keys and associated certificates necessary for SSL connections.

2. Vault Flag:

• How to Enable: Toggle the Vault switch to “ON” for the Key Store password.

• Functionality: When enabled, this flag ensures that the password for the Key Store is fetched from VAULT. Password will be automatically fetched during runtime of the GLU.Engine.

Connectors Secure Trust Store

1. Purpose: The Trust Store holds certificates from trusted Certificate Authorities (CAs). These certificates are used to verify the identity of counterparties in SSL transactions.

2. Vault Flag:

• How to Enable: Toggle the Vault switch to “ON” for the Trust Store password.

• Functionality: Similar to the Key Store, enabling this flag secures the Trust Store password in the VAULT. Trust store password will be automatically fetched during runtime of the GLU.Engine.

Global variable

The Vault Switch allows you to determine whether a specific variable’s value will be stored in a secure vault (e.g., Azure Key Vault or AWS Secrets Manager) for each environment. This is crucial for protecting sensitive data such as API keys, passwords, and other credentials.

Key Components:

Name Field:

• Specifies the variable name. In this example, the variable is named pinToAllTheMoney.
• The variable name for a global variable will become the Secret-name as used in the PAM.

Encrypted Checkbox:

• When selected, the value of the variable will be encrypted only for variables which are stores in GLU.Ware if the variable value is stored in a PAM it will not be encrypted.

Vault Switch:

• The Vault Switch column on the right allows you to specify whether the variable for a particular environment will be retrieved from a PAM (such as Azure Key Vault or AWS Secrets Manager).
• Vault On: When the switch is enabled (checked), the variable value for that environment will be retrieved from the vault.
• Vault Off: When the switch is disabled (unchecked), the variable value will not be retrieved from a vault, and the value on the dialogue box will be used.

How to Use the Vault Switch:

• For each environment where you need enhanced security, toggle the vault switch on. This ensures that the variable’s value will be retrieved from the vault at runtime.
• If the switch is off, the value will not be stored in the vault, and the value stored in GLU.Ware as entered in the dialogue box will be used.

1. Submit Changes:

• Once you have configured the vault settings for each environment, click Submit to save your changes. Refer to section “Build Manager – Getting the Secret-name for the VAULT” to understand how to retrieve a list go Secret-name ‘s which need to go in the PAM.

Best Practices for Using Vault Switch:

• Sensitive Data: Always enable the vault switch for environments where the variable holds sensitive information (e.g., passwords, API tokens). This prevents the exposure of secrets in less secure storage locations.
• Consistency: Use the same vault provider (Azure Key Vault, AWS Secrets) across all production environments for consistency and easier management.
• Testing: In testing environments, you may choose to store the variables outside of the vault if the data isn’t sensitive. However, always ensure that sensitive data in production environments is secured in the vault.

Example:

In the screenshot example:

• The variable pinToAllTheMoney is defined for various environments.
• To secure this sensitive PIN in production environments, toggle the Vault switch on for environments like “EN10-production” and “Production”.
• For non-sensitive environments (e.g., “Voucher Test”), you may choose to leave the vault switch off.

By following these steps, you ensure that sensitive data is stored securely in the vault while maintaining flexibility for other environments where vault storage may not be necessary.

Build Manager – Selecting you PAM

This dialog box is part of the GLU.Engine Build Manager interface, allowing users to configure the environment and key settings for their GLU.Engine startup process. The key feature is the ability to specify which Vault provider (either Azure Key Vault or AWS Secrets Manager) will manage your secret credentials at runtime.

GLU.Engine requires secret credentials (such as database passwords, API keys, etc.) to authenticate services and API connections during startup. These credentials are securely stored in either Azure Key Vault or AWS Secrets Manager, depending on your selection. Proper API connections between GLU.Engine and the selected vault provider are essential to ensure that the secrets are retrieved successfully when the engine is launched. (For more information about how the API connection is made during start up of the GLU.Engine please contact GLU Support.)

Key VAULT Components of the Dialog Box:

Select Vault:

• This dropdown allows you to choose where the GLU.Engine will retrieve its secret credentials at startup.
• Vault Azure: This option selects Azure Key Vault as the credential storage provider.
  • Azure Key Vault is Microsoft’s cloud-based service for securely storing and accessing sensitive information like API keys, passwords, and certificates.
• Vault AWS: This option selects AWS Secrets Manager as the credential storage provider.
  • AWS Secrets Manager is Amazon Web Services’ solution for storing and managing secrets securely in the cloud.

Important Considerations:

• Ensure the API connection to Azure Key Vault or AWS Secrets Manager is properly configured before starting the engine. Without this connection, the GLU.Engine will not be able to pull the required credentials, and the startup process will fail.

Build Manager – Getting the Secret-name for the VAULT

In the download screen accessible from the build manager it is possible to see a column with an indication that the build has been completed with VAULTs in place.

If the icon is selected then the Vault Keys dialogue will display this will show the Secret-name which should be used to store the secret against in the PAM environment.

An example of how this is configured in Azure Devops is provided below showing the Secret-name for the secret pinToALLTheMoney.

Benefits of Using Vault

• Security: Credentials are stored in a centralized, secure location and are not exposed in configuration files or UI.

• Manageability: Changes to credentials require updating the secrets in the VAULT only, without needing to redistribute configuration files.

• Compliance: Using Vault aids in compliance with regulations that require rigorous data security measures, such as GDPR, POPIA & NCPF.

Important Notes

• Ensure that the VAULT is properly configured at GLU.Engine runtime.

• Verify that all secrets (username, password) are correctly set up in the VAULT before enabling the Vault flags.

FAQs

Here are the questions followed by the responses for each:

Question 1:

What happens if the Secret-Name in the PAM does not exist or is misconfigured in GLU.Engine?

Response:
If the Secret-Name in the PAM (Azure Key Vault or AWS Secrets Manager) does not exist or is misconfigured, GLU.Engine will fallback to using the existing secret stored in GLU.Ware. This behavior could occur if the vault retrieval fails, which could lead to the engine using outdated or less secure credentials.

Question 2:

What occurs when the APIs connecting GLU.Engine to the PAM are misconfigured?

Response:
If the APIs to connect GLU.Engine to the PAM are misconfigured, the GLU.Engine will not start. This is because the necessary secrets for authentication or service configuration will not be retrieved from the vault, causing the startup process to fail.

Question 3:

How does the Vault Keys dialogue display Secret-names for global variables in GLU.Engine?

Response:
The Vault Keys dialogue displays all the Secret-names for all global variables that GLU.Engine can access, where the VAULT tickbox is checked. This helps users view which secrets are managed in the vaults (Azure Key Vault or AWS Secrets Manager) and ensures they are correctly stored and retrieved.

• Data Masking: This technique involves obscuring sensitive data within outputs to ensure that the data cannot be reconstructed or retrieved in its original form. Masking is applied to logs and JMX API responses to prevent sensitive information from being exposed. For instance, a masked credit card number might appear as ************* in logs.

• Data Encryption: In addition to masking, the GLU.Engine employs encryption to protect data at rest and in transit. Encryption involves converting data into a coded format that can only be read or processed after being decrypted with a key. This ensures that even if data is intercepted, it remains unreadable without the corresponding decryption key.

• JMX API Data Protection: Enhanced security measures are also applied to data accessed through JMX API calls. This includes both masking and encrypting data to ensure robust security against unauthorized access.

• Comprehensive JVM Data Security: The security measures extend throughout the JVM, safeguarding data involved in various processes and stored in memory spaces within the GLU.Engine. This integrated approach ensures that all sensitive data handled by the system is thoroughly protected.

• Flexible Tagging for Data Protection: Administrators can define specific security rules for data handling and protection in the ‘Mask PAYLOAD Values in Logs’ section of the Transaction Manager Panel. This allows for targeted application of masking and encryption rules across different data types and system interactions.

This strategic implementation of data masking and encryption within the GLU.Engine not only shields sensitive data from unauthorized access but also ensures the integrity and confidentiality of data across the platform’s operational framework.

In situations where the parameters in the messages may contain sensitive information that could pose a security risk if displayed in the logs, the GLU.Engine generates two types of logs that require controlled value representation:

1. logs that include parameters in the ‘PAYLOAD’ and
2. logs that print parameters as ‘PARAM’.

The masking of sensitive data in log entries can be controlled by configuring the PAYLOAD and PARAM log masking.

The PAYLOAD log masking is managed at the transaction level, while the PARAM log masking is managed at the parameter configuration level. It is important to note that while the PAYLOAD log masks only parameters in the PAYLOAD when printed in the log, the mask does not affect the unmarshalled value.

To mask the unmarshalled value, a mask for the full string as it appears in the logs must be added.

Then the PARAM log will be masked in the values when un-marshalled.

To mask PAYLOAD values, the ‘Mask PAYLOAD Values in Logs‘ field in the Transaction Manager Panel can be used to define the ‘tags‘ for any values that need to be masked, along with the GLU reserved word “GLU_MASK” (e.g. “username”:”GLU_MASK”).

This will replace the value for “username” with “**********”.

Since tags are used, any payload value can be masked, not just the parameter values within the payload.

The tags to be masked can be copied from the payload template configuration and will vary depending on the payload type (e.g. XML, JSON, SQL call, etc.).

NOTE: the GLU_MASK value used is the full line, so if you complete the line entry with “username”: “GLU_MASK”, the value will also be included in the masking of username – e.g. “**********”.

To mask PARAM values, the “Mask PARAM Value in Logs“ checkbox (which by default is ‘checked’) must be unchecked.

Any payload tag (PAYLOAD logs) or parameter name (PARAM logs) that is configured to be masked will be masked in in all logs (INFO, WARN, DEBUG etc.) for all logs associated with a particular transaction.