One of the more common security issues organizations face today is helping ensure that users with elevated privileges rotate their passwords for various internal resources on a regular basis. To help enforce password rotation, organizations typically implement automatic password expiration timeframes, commonly set for every 30, 60 or 90 days. These privileged users receive several notifications in the weeks and days leading up to the expiry date, reminding them to change their expiring password before the date to avoid being locked out.
While a step in the right direction, this approach still has drawbacks that affect both the privileged users and the security organization. For example, even with multiple notices, privileged users forget to change their password, simply because they’re too busy or they’re on vacation on the expiration date. Or maybe they remember to rotate the password, but then they forget what they changed it to. In any case, the result is the same: frustrated users as well as frustrated IT personnel, both of whom are losing valuable time in the process.
Because of all these reasons and more, many security organizations avoid enforced password rotation for privileged accounts altogether, leaving gaping holes in infrastructure security across the organization.
But there is a better approach to password rotation: look at this as a coding problem with a coding solution. What do I mean by this? By automating the rotation of secrets through code that runs in the background, no engineering resources are required to manually enforce password rotation and no users are burdened with having to remember to rotate passwords. It’s potentially a win – win. Security organizations can help avoid human error, reduce the time to enforce or fix problems, improve adoption of better password security and, perhaps most importantly, help ensure compliance and make quarterly compliance reviews less tedious.
At Adobe, we’ve implemented an automated secret rotation process for certain categories of user accounts, as well as through a pilot project within one of our teams for shared infrastructure resources.
In general, here is how it works:
First, you create a spec file that includes scripts for two processes: rotating the passive secret (Step 1 in the diagram below) and applying the new passive secret to the active key (Step 2 below).
To rotate a passive secret for the Azure container registry, the code in the spec file would look something like this (NOTE: all examples shown are generic and for illustrative purposes only):
azure:
container_registry:
- name: testregistry
active_key_value: “{{ docker_acr_repo_password }}”
passive_key_path: ‘IO_XT/qcrdemo:container_registry_passive’
resource_group: “test-resource-group”
Next, you would leverage the AWS and Azure command line interfaces to rotate the passive secret to the new value. For example:
az acr credential renew -n testregistry --password-name password2
Finally, you need to apply the newly rotated passive secret to the active key. The spec file code for that process looks like this:
_vault: common: address: https://your_vault_address mount_point: kv namespace: your_vault_namespace version: 2 paths: artifactory_corp_username: 'test/Artifactory/corp:username' artifactory_corp_password: 'test/Artifactory/corp:password' az_sp_passsword: 'test/Azure_Credentials/nonprod:az_sp_passsword' az_sp_tenant: 'test/Azure_Credentials/noprod:az_sp_stage_tenant' az_sp_user: 'test/Azure_Credentials/noprod:az_sp_user' docker_acr_repo_password: 'test/qcrdemo:container_registry_active'
One more note: this approach can be accomplished in many ways, including through customized implementation of open-source secrets storage tools, and/or through use of whatever other secure storage mechanisms makes sense for your company. And no matter where you choose to store your secrets, by treating security – and password rotation – as code, you can help improve security across your organization.
Shikha Chawla
Software Development Engineer, Platform