Deployment Task

There have been increased requests from prospects and customers to have credentials used for integration with other technologies within the Aqua console to be managed by a Privileged Access Management (PAM) tool such as BeyondTrust, CyberArk, and CA.

An example will be a credential used by Aqua to connect to a private registry. In many cases, these credentials are deemed sensitive and must be frequently rotated. However, these credentials are hardcoded in our configuration and need to be manually rotated. This means a user must change the credential to access the registry and then manually update the new credentials into Aqua.

Deployment Steps

In order to simplify the process and provide accountability, most users will want the registry credentials to be automatically rotated by the PAM solution. The problem is after the rotation, the new credential must still be updated manually into Aqua and there will be short periods of disruption for Aqua to access the registry, since Aqua is still holding the old credentials.

In order to address this and make the process automated and secure so that Aqua have the new credentials immediately after rotation, we can look at 2 methods.

Method 1 - Aqua pulls the new credential

Have Aqua to pull the secret at fixed intervals so that any changes made by the PAM solution in the credentials for the registry will be picked up by Aqua quickly.

Most PAM solutions have an application access manager solution that will allow the application which needs these credentials to pull them. An example will be the CyberArk Application Access Manager

However, this method typically requires an agent to be installed in the calling application server and requires modification to the made to the application to use APIs provided by the agent. In our case, it requires R&D integration effort. Therefore, it is not practical

Method 2 - Have the PAM solution push the secret to Aqua

This method is the preferred method. In this method, a shell script can be provided to the PAM provider so that when the PAM solution changes the registry credential password, in the same password change process, it will call the provided script and then update the new credentials into Aqua via Rest APIs on the fly automatically.

The shell script does 2 things:

  • Invokes a login into Aqua with a user having permissions to update the credentials (credentials injected by PAM)
  • Prompts for the new credentials (which will be injected by the PAM) and then updates Aqua with these new credentials

This method is more viable since there is no need for R&D effort. The entire process of changing the password in the registry by the PAM solution and then updating it into Aqua is a single process so error checking can be performed by the PAM vendor to make sure it is the new and right credential passed into Aqua.

Here is an example of the shell script:

Script to allow PAM solution to update registry password after rotation

It’s a bash script and here is how the PAM solution can use it:

  • ./ aqua_username aqua_password
  • It will prompt for the new registry password with this prompt: Enter New Password: 
  • Once new password goes in, it will update the Aqua config with the new registry password
  • If there are no errors, the prompt will return a zero exit code (empty) and the process is completed
  • If there are errors and we cannot use the new credentials to login into the registry, we will throw this error message: {"message":"Failed updating registry: failed authenticating with registry, please verify credentials","code":500}

#Get credentials for REST API authentication

#Get auth token
TOKEN=$(curl -X POST \
$aqua_server \
-H 'Content-Type: application/json' \
-H 'cache-control: no-cache' \
-d '{ "id": "'$1'", "password": "'$2'" }' \
| jq -r '.token')

#Read new registry password
read -s -p "Enter New Password: " npswd

#Update new password
curl -X PUT \
$registry_path \
-H 'Authorization: Bearer '${TOKEN}'' \
-H 'Content-Type: application/json' \
-H 'cache-control: no-cache' \
-d '{
"name": "'$registry_name'",
"type": "V1/V2",
"url": "'$registry_url'",
"username": "'$registry_user'",
"password": "'$npswd'",
"auto_pull": true,
"auto_pull_time": "02:30",
"auto_pull_max": 100

The diagram below is a screenshot from BeyondTrust as to how they will call the provided script and then inject in the needed credentials in order to automate the entire process: