Skip to content
Download

Connectors

AWS, builder

Your Odds build in your AWS account: they create and change Lambda functions, S3 buckets, EC2 servers and the rest. They cannot change who has access, and they never see a secret’s value. It takes about five minutes.

How it stays safe

Your Odds work in AWS as a role you make, and AWS itself holds them to it. The role is AWS’s own power-user access, which leaves out IAM, with a Deny on secret values. Before it connects, the office tries to read a secret as that role, and refuses to connect if AWS answers with a value.

At Acts on its own, an Odd with Read and write builds without asking each time. At Drafts for your yes, each change waits on your desk for your yes. What it creates costs what AWS charges, so keep an eye on your bill.

Before you start

  1. Do the AWS sign-in guide first, if you have not for another AWS tool.

  2. Install uv on this computer. Oddboro starts AWS’s tool with it.

    On a Mac or Linux, in a terminal:

    curl -LsSf https://astral.sh/uv/install.sh | sh

    On Windows, in PowerShell:

    powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
  3. Have an Odd ask you for AWS, builder, and approve it with Read and write. Its connect task lands on your desk.

Part 1. Make the builder role (in AWS)

Your Odds use this role. It is AWS’s own power-user access, which leaves out IAM, with a Deny that keeps secret values out of reach.

  1. Open IAM Identity Center, signed in to the AWS console as an administrator.

    https://console.aws.amazon.com/singlesignon Go to (opens in a new tab)

  2. 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.

  3. Click Create permission set.

  4. Choose Custom permission set.

  5. Click Next.

  6. Expand AWS managed policies.

  7. Search for PowerUserAccess.

    PowerUserAccess

  8. Tick PowerUserAccess.

  9. Expand Inline policy.

  10. Replace what is in the box with this policy.

    The Deny wins over anything else the role is given, so Odds never read a value from Secrets Manager or Parameter Store.

    {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "secretsmanager:GetSecretValue",
        "secretsmanager:BatchGetSecretValue",
        "ssm:GetParameter",
        "ssm:GetParameters",
        "ssm:GetParametersByPath",
        "ssm:GetParameterHistory"
      ],
      "Resource": "*"
    }
  ]
}

  11. Click Next.

  12. For Permission set name, type this.

    OddboroBuild

  13. Click Next.

  14. Click Create.

Part 2. Give it to the Oddboro user (in AWS)

  1. In the left menu, click AWS accounts.

  2. Tick the account you want Oddboro in.

  3. Click Assign users or groups.

  4. 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.

  5. Click Next.

  6. Tick OddboroBuild.

  7. Click Next.

  8. Click Submit.

    Wait until the page says it is done.

Part 3. Find the Region your work is in (in AWS)

  1. Open the AWS console.

    https://console.aws.amazon.com Go to (opens in a new tab)

  2. Open a service you use, such as Lambda or EC2, and find your resources.

  3. Click the Region menu at the top right, and note the Region it shows.

    Note its code, such as us-east-2. Your Odds start there, and can reach other Regions by naming them.

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.

  1. In Oddboro, click Desk.

  2. Open the task named Connect AWS, builder for your Odd.

  3. Paste your portal URL into AWS access portal URL.

  4. Type your Identity Center Region into Identity Center Region.

  5. Click Sign in.

    AWS’s page opens in a new tab with a code. The desk shows the same code.

  6. On AWS’s page, check that the code matches.

  7. Sign in as oddboro.

    Or as your own user, if AWS would not let you add one for Oddboro.

  8. Allow Oddboro office access when AWS asks.

    Back on the desk, the role list appears.

  9. For “The role your Odds build in AWS with”, pick OddboroBuild.

  10. Type your Region into “Region your work is in”.

  11. Click Check and connect.

    The office tries to read one secret as this role. When AWS refuses, the step ticks and the office starts AWS’s tool. The first time takes a minute or so.

Try it

Ask the Odd, “Make me an S3 bucket called oddboro-test.” It makes it. Ask it to delete the bucket when you are done.

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.
“That role can read secret values, and Odds must never see one.”
The role is missing the Deny. Check its inline policy against the one above, then click Check and connect again.
“There are no secrets yet, so the office could not test …”
The office connected without testing the role. Store one secret in Secrets Manager, click Undo on the step, then Check and connect again.
“Oddboro starts AWS’s tool with uv, and this computer does not have it.”
Install uv (Before you start), then click Check and connect again.
A deploy fails while creating an IAM role.
Builder cannot change IAM, so an Odd cannot make or change roles. Create the role yourself, then tell the Odd its name.