Password managers: reading secrets from CyberArk, Delinea, Vault and Azure Key Vault

Lighthouse signs in to many things: CAs, Windows servers, appliances, cloud vaults, mail relays, ticketing systems. By default each password or token is a stored secret on the computer that uses it (lh secret set <name> on the server, DPAPI-protected; lh-outpost secret set <name> or Settings, Outposts, Secrets on an Outpost).

With the optional feature Password managers (Settings, Features; in every license), Lighthouse can instead read any of them from the password manager or secrets vault your organisation already uses, at the moment it needs it:

The first part of a reference is the name you give the password manager in Lighthouse, so you can have several of the same product (cyberark-prod:…, cyberark-dmz:…).

What Lighthouse promises

• Read at the moment of use, never kept. The value is handed to the step that needs it and kept nowhere: no cache, no file, no database row, no log line. The next use reads again, so a password the manager rotates is the one used next time.
• Signs in as itself where the product allows, so there is no extra password to look after: the gMSA on the server, the Outpost's own account on an Outpost.
• Every read is in the Keeper's Log, with the reference and what it was for, never the value: password-manager-read, or password-manager-read-failed with the product's reason.
• A refusal stops at once. HTTP 401 or 403 from the product fails the step with its reason, and nothing is retried.
• Outposts read for themselves. A job that runs from an Outpost reads its references on the Outpost's computer, with the Outpost's own sign-in. Lighthouse sends it the password manager's settings, which hold no secrets, and never sees the value (the same rule as Outpost secrets).
• TLS is always checked, redirects are never followed, and only https addresses are accepted.

Setting it up

1. Settings, Features: turn on Password managers.
2. Settings, Connections, Password managers, Add password manager: pick the product, give it a short name (references start with it, and it cannot be changed later), its address and how Lighthouse signs in.
3. Try a reference: Lighthouse reads it as this server and says whether that worked, never what it read.
4. Write the reference wherever a stored secret's name goes. For example, on a Windows Installation's Sign in as, the password secret cyberark:Windows/svc-install.
5. For one of Lighthouse's own fixed-name secrets (only these can point) (smtp-password, teams-webhook, slack-webhook, jira-token, servicenow-password, ai-model-key, an OpenID Connect provider's signin-<id>), add a pointer under Lighthouse's own secrets: Lighthouse then reads that name from the password manager. Remove the pointer and the stored value, if any, is used again. Secrets Lighthouse makes itself (keepers-log-seal, scep-ra, acme-key-*, webhook signing secrets and the password managers' own password-manager-*) cannot be pointed anywhere.

Where references can go: a Windows Installation's Sign in as password, PFX and keystore passwords, network appliance passwords, cloud vault credentials, Jamf's client secret, DigiCert, Sectigo and GoDaddy API keys and passwords, a Vault CA's token or AppRole secret id, an ACME CA's EAB HMAC key and Cloudflare token, and a job's own SMTP password or Teams webhook.

In each product

Give Lighthouse read only on the secrets it needs, and nothing else.

CyberArk (Central Credential Provider)

1. In the PVWA, add an Application for Lighthouse, such as Lighthouse. That is the Application id.
2. Choose how the CCP recognises Lighthouse, and set the same under Signs in:
   • OS user (recommended): add the service account as an allowed OS user, such as EXAMPLE\gmsa-lighthouse$, and turn on Windows authentication for the AIMWebService application in the CCP's IIS. Lighthouse signs in with Negotiate (Kerberos) as that account.
   • Client certificate: issue the server a client certificate, put it with its key in LocalMachine\My, allow the service account to read the key, and give the thumbprint.
   • Allowed Machines: the addresses of each Lighthouse server and Outpost. Use it only together with one of the above where you can.
3. Give the application Retrieve accounts on each safe Lighthouse reads from (add the application, and the CCP's Provider user, as safe members).
4. Address: the CCP's base address, such as https://ccp.example.com. Lighthouse adds /AIMWebService/api/Accounts.

Delinea Secret Server

• Windows authentication (recommended): turn on Integrated Windows Authentication for winauthwebservices, and give the service account View on the secrets (or their folder). Address: https://secrets.example.com/SecretServer.
• Application account: make an application account with View on the secrets. Give its user name, and type its password once in the dialog (kept in this server's secret store as password-manager-<name>). Secret Server Cloud: address https://<tenant>.secretservercloud.com.
• References use the secret's id (in its address in Secret Server) and the field's slug: password unless you add /username, /private-key and so on.

HashiCorp Vault (KV)

• AppRole (recommended): make a role with a policy that only reads the paths Lighthouse needs, for example path "secret/data/lighthouse/*" { capabilities = ["read"] }. Give the role id, and type the secret id once (kept as password-manager-<name>).
• Token: a read-only, renewable token with that policy, typed once.
• Give the KV mount (secret by default), its version (2 by default) and, on Vault Enterprise or HCP, the namespace.

Azure Key Vault

• Managed identity (recommended, when Lighthouse runs in Azure): give the VM's identity the role Key Vault Secrets User on the vault. For a user-assigned identity, give its client id.
• App registration: give its tenant id and client id, type its client secret once, and give the app Key Vault Secrets User.
• Address: the vault's Vault URI, such as https://example-kv.vault.azure.net.

Any other vault: PowerShell SecretManagement

For a vault Lighthouse has no reader for, use Microsoft's SecretManagement module with that vault's extension. Lighthouse ships none of the vault's code: it runs one fixed script that calls Get-Secret, with the vault's name, the secret's name and the key passed as environment variables, never as script text, so nothing typed becomes code. The value comes back base64-encoded on standard output and is never in the script, so PowerShell's script block logging does not see it.

On each computer that reads (the Lighthouse servers, and any Outpost that runs those jobs):

1. Install the modules for all users in Windows PowerShell 5.1, which Lighthouse runs on Windows: Install-Module Microsoft.PowerShell.SecretManagement, <the vault's extension> -Scope AllUsers. (On a Linux Outpost, Lighthouse runs pwsh.)
2. Register the vault as the account Lighthouse runs as, since vault registrations belong to the user: for a gMSA, run Register-SecretVault -Name <vault> -ModuleName <extension> -VaultParameters @{...} from a scheduled task that runs as the gMSA, once.
3. Set the vault up to need no prompt (no master password typed at run time). Use the extension's own way to sign in non-interactively, such as a key file readable only by that account.
4. In Lighthouse, add a password manager of the kind Any other, through PowerShell SecretManagement with that vault name, and try a reference.

The built-in readers above are still the better choice for CyberArk, Delinea, Vault and Azure: they sign in as Lighthouse itself with no module to keep up to date, and their errors say exactly what the product refused.

On an Outpost

The Outpost reads with its own account and its own secrets, so set up the product for it too:

• Windows authentication or OS user: allow the Outpost's service account as well.
• Client certificate: the certificate goes in the Outpost computer's LocalMachine\My.
• A password, token, secret id or client secret: set it on the Outpost under the same name, password-manager-<name> unless the dialog gives another, with Settings, Outposts, Secrets or lh-outpost secret set.

Try a reference checks the server's access only; run the Outpost's job once to check its own.

When something is wrong

What is not done yet

• Writing back to a password manager (for example, keeping a PFX password or a new key there) and rotating passwords from Lighthouse.
• Built-in readers for AWS Secrets Manager, BeyondTrust Password Safe, CyberArk Conjur and Google Secret Manager (SecretManagement covers those with an extension).
• A Try that runs on an Outpost.