Skip to content

Connectors

AWS, read only

Your Odds read your AWS account: CloudWatch logs, S3 files, Lambda functions and the rest. They cannot change anything, 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 read-only access, 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.

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, read only, and approve it. Its connect task lands on your desk.

Part 1. Make the read-only role (in AWS)

Your Odds use this role. It is AWS’s own read-only access, with a Deny that keeps secret values out of reach.

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

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

    ReadOnlyAccess
  8. Tick ReadOnlyAccess.

  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.

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

  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.

  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, read only 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 read AWS with”, pick OddboroRead.

  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, “What Lambda functions do I have?” It lists them. Ask it to change one, and AWS refuses it.

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.