Editor’s Note: CyberArk Secrets Hub is a relatively new product designed to unify secrets management across hybrid and multi-cloud environments. It supports syncing secrets from AWS, Azure Key Vault, and more, into a centralized, policy-controlled interface.
Last year, I set up CyberArk Secrets Hub as part of a proof-of-concept (POC) with support from third party team. Everything worked. So naturally, I thought I had it figured out. Fast forward to this year—I rebuilt the environment on my own for DEV, only to hit a brick wall.
Scene 1: Same Setup, New Problem
In a CyberArk ISPSS DEV instance, I have setup Secrets Hub and it was already working smoothly with Azure Key Vault, so when I tried connecting it to AWS Secrets Manager again, I assumed reusing the same IAM role would “just work.”
It didn’t.
No matter how many times I reviewed the trust policy, the connection kept failing. AWS side looked OK. CyberArk side looked OK. But something wasn’t clicking.
“Hey, same AWS account, same goal, same role. What could possibly go wrong?”
Famous last words. Despite Azure Key Vault integration working flawlessly, the AWS connection stubbornly failed. And so began the debugging journey.
Scene 2: The Case of the Mismatched Trust Policy
Naturally, I started reviewing the IAM role’s trust policy. The structure seemed familiar. But then I spotted something subtle—nothing the UI pointed out, just raw JSON and a healthy dose of skepticism.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::428013889450:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"ArnEquals": {
"aws:PrincipalArn": "arn:aws:iam::428013889450:role/SecretsHub-Role-5a490b41-fa26-400b-ba0f-c84ebb4c5ffe-XXXXXXXX"
}
}
}
]
}
This line restricts which CyberArk Secrets Hub role can assume the IAM role—down to the exact ARN. And that ARN? It belonged to my previous Secrets Hub instance. That’s when it clicked: – The CyberArk AWS account (428013889450) is shared, – But the role ARN is unique per Secrets Hub instance.
The Ah-Ha Moment: Secrets Hub Role ARN is Instance-Specific
At first, I didn’t realize that every Secrets Hub instance comes with a unique AWS role ARN.
But thinking it through, it actually makes perfect sense. CyberArk ISPSS is a multi-tenant cloud service, hosting hundreds—if not thousands—of Secrets Hub instances for different customers. Of course each instance needs a unique ARN to securely isolate access.
This wasn’t something explicitly stated in the UI or docs—just something I had to piece together from the way the trust policy was structured.
What the Docs Don’t Tell You
And here’s the real issue.
CyberArk documentation does highlight the importance of IAM role configuration—especially in Add a single AWS secret store. But when it comes to how to configure that role, Configure AWS account roles for Secrets Hub provides only Terraform and CloudFormation templates.
That’s great for infrastructure-as-code users. But for anyone trying to validate a POC using the AWS Console, it’s basically a guessing game.
Worse: nowhere in the documentation does it say where to find the CyberArkSecretsHubRoleARN.
It keeps telling you “Set the trust policy using the Secrets Hub tenant role ARN”—but unless you’ve seen it before, how would you know where to get it?
Eventually, I found it by logging into Secrets Hub and navigating to Settings > Secrets Hub Role ARN. But this felt more like an Easter egg than a documented step.
How It Should Be Done (The Right Way)
Step 1: Trust Policy with Instance-Specific ARN
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::428013889450:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"ArnEquals": {
"aws:PrincipalArn": "arn:aws:iam::428013889450:role/SecretsHub-Role-<your-current-instance-ARN>"
}
}
}
]
}
You can find the correct ARN by logging into CyberArk Secrets Hub, then navigating to Settings > Secrets Hub Role ARN.
Step 2: Permission Policy (With Tag + Region Constraints)
Based on the official article Configure AWS account roles using Terraform | CyberArk Docs the equivalent permission policy in JSON:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "secretsmanager:CreateSecret",
"Resource": "arn:aws:secretsmanager:${var.SecretsManagerRegion}:${var.SecretsManagerAccount}:secret:*",
"Condition": {
"StringEquals": {
"aws:RequestTag/Sourced by CyberArk": [""]
}
}
},
{
"Effect": "Allow",
"Action": "secretsmanager:ListSecrets",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestedRegion": "${var.SecretsManagerRegion}"
}
}
},
{
"Effect": "Allow",
"Action": [
"secretsmanager:UpdateSecret",
"secretsmanager:PutSecretValue",
"secretsmanager:DeleteSecret",
"secretsmanager:DescribeSecret",
"secretsmanager:TagResource",
"secretsmanager:UntagResource"
],
"Resource": "arn:aws:secretsmanager:${var.SecretsManagerRegion}:${var.SecretsManagerAccount}:secret:*",
"Condition": {
"StringEqualsIgnoreCase": {
"aws:ResourceTag/Sourced by CyberArk": ""
}
}
},
{
"Effect": "Allow",
"Action": [
"secretsmanager:TagResource",
"secretsmanager:UntagResource"
],
"Resource": "arn:aws:secretsmanager:${var.SecretsManagerRegion}:${var.SecretsManagerAccount}:secret:*",
"Condition": {
"ForAllValues:StringEqualsIgnoreCase": {
"aws:TagKeys": [
"Sourced by CyberArk",
"CyberArk Extended Access"
]
},
"StringNotEqualsIgnoreCase": {
"aws:ResourceTag/Sourced by CyberArk": ""
}
}
},
{
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue"
],
"Resource": "arn:aws:secretsmanager:${var.SecretsManagerRegion}:${var.SecretsManagerAccount}:secret:*",
"Condition": {
"StringEqualsIgnoreCase": {
"aws:ResourceTag/CyberArk Extended Access": "true"
}
}
}
]
}
Lessons from Configuring CyberArk Secrets Hub with AWS
Here’s what I wish someone told me earlier:
-
Each Secrets Hub instance has its own role ARN.
Do not reuse from previous environments. -
Trust policy must match the instance’s ARN exactly.
-
If you’re not using Terraform, manually build both trust + permission policies in AWS Console.
-
Docs assume too much Terraform knowledge.
And they never explicitly tell you where to find critical values like the role ARN.
Final Thoughts
This wasn’t a production outage. Just a side-quest from my dev environment. But it reminded me how a seemingly minor mismatch—like an outdated ARN—can kill your integration and cost hours of troubleshooting.
Hopefully this helps you skip the pain.
Have you faced similar AWS/CyberArk surprises? Share your pain or tricks in the comments or connect with me on LinkedIn.