Connectors
AWS Secrets Manager
Your Odds see the names of the secrets you keep in AWS, never their values. Other tools can take their keys straight from AWS, so you never paste one into Oddboro. It takes about five minutes.
How it stays safe
Anything an Odd reads goes to its AI model, so Odds never get a secret’s value. The office reads secrets itself, with a role you make for it. It gives your Odds only the names, and it reads a value only to hand a key straight to the tool that needs it.
Before you start
- Do the AWS sign-in guide first, if you have not for another AWS tool.
- Have an Odd ask you for AWS Secrets Manager, and approve it. Its connect task lands on your desk.
Part 1. Make the office’s role (in AWS)
The office uses this role to list your secrets’ names for your Odds, and to read a value only when another tool needs its key.
Open IAM Identity Center, signed in to the AWS console as an administrator.
In the left menu, under Multi-account permissions, click Permission sets.
No Multi-account permissions in the menu? Turn it on first: the AWS sign-in guide shows how.
Click Create permission set.
Choose Custom permission set.
Click Next.
Expand Inline policy.
Replace what is in the box with this policy.
It reaches every secret. To keep some out of reach, change "*" to the secrets you want, such as arn:aws:secretsmanager:*:*:secret:oddboro/*.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "secretsmanager:ListSecrets", "secretsmanager:DescribeSecret", "secretsmanager:GetSecretValue" ], "Resource": "*" } ] }Click Next.
For Permission set name, type this.
OddboroSecretsClick Next.
Click Create.
Part 2. Give it to the Oddboro user (in AWS)
In the left menu, click AWS accounts.
Tick the account you want Oddboro in.
Click Assign users or groups.
On the Users tab, tick oddboro.
The user from the AWS sign-in guide. If you signed in to Oddboro as another user, tick that one: the role goes to whoever Oddboro signed in as.
Click Next.
Tick OddboroSecrets.
Click Next.
Click Submit.
Wait until the page says it is done.
Part 3. Find the Region your secrets are in (in AWS)
Open Secrets Manager.
Switch to the account your secrets are in first, such as your project’s account, not the management account.
Click one of your secrets.
If the list is empty, change the Region menu at the top right until you see them.
Find its Secret ARN, and note the Region in it.
The Region is the part after secretsmanager:, here us-east-2.
arn:aws:secretsmanager:us-east-2:123456789012:secret:prod/stripe
Part 4. Connect it from your desk (in Oddboro)
If the office is already signed in to AWS, for another AWS tool, the step skips straight to step 9.
In Oddboro, click Desk.
Open the task named Connect AWS Secrets Manager for your Odd.
Paste your portal URL into AWS access portal URL.
Type your Identity Center Region into Identity Center Region.
Click Sign in.
AWS’s page opens in a new tab with a code. The desk shows the same code.
On AWS’s page, check that the code matches.
Sign in as oddboro.
Or as your own user, if AWS would not let you add one for Oddboro.
Allow Oddboro office access when AWS asks.
Back on the desk, the role list appears.
For “The role the office reads your secrets with”, pick OddboroSecrets.
Type your Region into “Region your secrets are in”.
Click Connect.
The step ticks. Your Odds can list your secrets’ names, and other tools’ key steps offer “Use a secret from AWS instead”.
Take another tool’s key from AWS
When a tool’s connect task asks for a key, name a secret instead of pasting it.
- On the key step, click Use a secret from AWS instead.
- Pick the secret.
- If it holds JSON, type the key inside it, such as api_key.
- Click Use it.
Try it
Ask the Odd, “Which secrets do I have in AWS?” It lists their names.
If something goes wrong
- “Your AWS user has no roles yet.”
- The oddboro user has no permission set in that account yet. Do the “Give it to the Oddboro user” part, wait a minute, then click Look again.
- AWS asks me to sign in again every day.
- Identity Center ends a sign-in after 8 hours unless you change it. In IAM Identity Center, click Settings, then the Authentication tab, then Configure next to Session duration. It goes up to 90 days.
- A key from AWS fails with AccessDenied, mentioning KMS.
- That secret is encrypted with a KMS key of your own. Add kms:Decrypt on that key to the OddboroSecrets permission set.