The Best Way to Share AWS Credentials is Not To: Setting Up AWS SSO for Startups

Contents

Why Most AWS Security Setups Fail

Most developers know shared credentials are bad and that dev work shouldn’t touch production data, but every ‘proper’ solution feels like enterprise theater when you’re trying to ship.

The real challenge is figuring out how to set up proper access controls and environment isolation without spending days reading AWS documentation, implementing something that breaks your development workflow, or getting locked into an expensive solution.

AWS Organizations and IAM Identity Center give you everything your company needs: short-lived credentials, per-environment account isolation, consolidated billing, and centralized access management - without paying for an expensive single sign-on (SSO) provider.

I’ve used this setup at two companies now: a fintech startup handling contractors, FTEs, and compliance audits; and the company I founded - Sabal Finance - to securely manage contributors and security scans across multiple environments. The implementation is straightforward and free.

Here’s how to implement SSO, multiple accounts, and temporary credentials starting from a fresh AWS account in under 60 minutes.

First Steps: Creating an Account

If you don’t have an AWS account yet, head to aws.amazon.com and create one. You’ll need a credit card on file, but AWS offers startup credits through their Activate program if you’re eligible.

Pick your primary region during setup. Choose based on where your users are located or where you plan to deploy using AWS’s Global Infrastructure Map. For US startups, us-east-1 (Virginia), us-east-2 (Ohio), or us-west-2 (Oregon) all work well.

Once your account is active, you’ll see the AWS Management Console. This becomes your “management account” in AWS Organizations terminology - it’s where you’ll create and govern your environment-encapsulating accounts.

Setting up the Management Account

Navigate to the AWS Organizations service by searching for “AWS Organizations” in the console search bar, then click “Create an organization.” This creates your organization structure at no additional cost, though it does move your account from the free tier to standard pay-as-you-go pricing.

Your current account automatically becomes the management account, which you’ll use to create member accounts, manage billing, and configure organization-wide policies. You won’t deploy applications here - it’s just for governance.

Creating Member Accounts per Environment

AWS Organizations centralize control over a collection of member accounts. We’ll make one account for each deployment environment and configure what our IAM users have access to in each account.

From the Organizations home page, click “Add an AWS account”. Then choose “Create an AWS account” - the “Invite an existing AWS account” option is for bringing external accounts into your organization. Name the account after a deployment environment, like “Dev” or “Prod”.

I use plus addressing (ex. you+aws{env}@{domain}) to create unique addresses that embed the environment name while routing to my main inbox.

Refresh the page after creation to see your new account. Repeat this process for each environment.

You might hit account creation limits when creating member accounts. When writing this article, I couldn’t create more than one additional account initially, so I had to open a support ticket requesting a quota increase to 3 accounts - shout out Harsh from AWS!

Harsh mentioned that while the default quota is 10 accounts, sometimes that’s lowered based on account age, region, and account type (ex. personal vs business). Regardless, my ticket was resolved within two business days on the free support tier. I used a serverity of “General question” and category of “Service Quotas, General”.

Once you’re done creating member accounts, your organization view should look like the image above.

Specifying Your SSO Identity Source

Search for “IAM Identity Center” in the console and click “Enable” to get started.

IAM Identity Center vs IAM service

Don’t confuse IAM Identity Center with the similarly-named IAM service. The IAM Identity Center (formerly AWS Single Sign-On) works with AWS Organizations to set policies for the users and resources inside that organization. The IAM service handles permissions within individual accounts. They’re related concepts that work at different levels within AWS.

Creating an IAM Identity Center Instance

We need an IAM Identity Center instance to manage our organization’s SSO.

In the “Settings Summary” section, click “Go to settings”. This is where you configure your identity source - the canonical source of users who can access your organization.

In the “Details” section, click “Edit” next to the instance name to customize it.

Setting up an Identity Provider

An Identity Provider (IdP) is the canonical source of the people that make up your organization. They provide the “who” and service providers (SPs) provide the “what”. The AWS accounts that hold your deployment environments are services you want to provide access to based on the information stored in your IdP.

AWS as an Identity Provider

For startups, using IAM Identity Center as your identity provider is simple and cost-effective - it’s free. I’m using it for Sabal to avoid paying monthly SSO fees.

To get started, scroll down to “Identity source” and update the “AWS access portal URL” with a subdomain for your company (example: https://myapp.awsapps.com/start). Bookmark this URL - it’s where you’ll authenticate going forward.

Check the “Authentication” tab to configure MFA requirements and session durations. The default eight-hour session works for most teams, but it can be adjusted based on your security requirements.

Return to the IAM Identity Center dashboard to verify your changes appear in the “Settings Summary” section.

Other Identity Providers

I wanted to include a few notes about external IdPs I used at previous startups. One used Okta as an IdP and another used Google Workspace as an IdP. Both worked well-enough and supported SCIM, which lets you automatically provision people’s information in the service provider (AWS in our case). Okta worked well but is more expensive; Google Workspace was an easy choice because we were already using GSuite, but it’s AWS integration doesn’t support provisioning group information - I had to do that manually.

If you’re using an IdP that supports both user and group provisioning, you can skip the next section.

Users, Groups, and Permissions

The general pattern is to use a Group to represent a roles within the company. We’ll add users to these groups and assign groups permissions across accounts. For example,

• an Admin group would have broad access to Prod, Dev, and Management accounts
• a Developer group would have broad access to Prod and Dev
• a Contractor group would have access to some Dev services to write and test code
• a Compliance group would have access to specific Prod resources, like an audit trail bucket.

We’ll walk through manually provisioning an Admin group and user. Remember you have room to add narrowly scoped permissions, giving you room to grow.

Creating the Admin Group

From the IAM Identity Center page, click “Group”in the side pannel then click “Create group” in the top right. This opens up a simple form that prompts you for a name and description. Fill it in then click “Create group” in the bottom right to finish.

Creating your First Admin

From the IAM Identity Center page, click “Users”in the side pannel then click “Add user” in the top right. Fill in the form, paying attention to whether you want AWS to email the person a password or if you want to generate a one-time password to share yourself.

Scroll down and click “Next”, filling in optional sections as you see fit (I’d skip these for now).

You’ll see we have the option to add this user to a group. Check the Admin group we created previously and click “Next”. Verify the information then click “Add User” at the bottom of the page.

At this point, the user will be created in the Identity Center and a login email containing a magic link and link to your SSO portal will be sent to specified email. When the magic link is clicked, the person will be able to set a new password for their username.

Defining Permissions for the Admin Group

We have our user in a group, but they’re not able to do anything. Permission sets describe the actions something - like a service, user, or group - can perform on a resource. You can think of them as roles, like you’d see in other authorization systems. Let’s create the permission set for our Admin group by clicking “Permission sets” in the sidebar followed by “Create permission set”.

Take a minute to look at the predefined permission sets. Their names and descriptions give a sense of the applications of managing group permissions in the Identity Center. Custom permission sets offer more granular control, like read-only access to specific resources.

We’re going to select AdministratorAccess for our Admin group.

Click “Next” to progress to the permission set details screen. Change the “Session duration” to match your security posture and then click “Next”.

Review the permission set details and - if everything looks good - click “Create”.

Granting Admin Permissions in Org Accounts

We’re ready for the last step: granting the AdministratorAccess permission set to the Admin group in the appropriate accounts.

From the IAM Identity Center page, click “AWS accounts”in the side pannel. We want our Admin user to have full access to each of the accounts, so check each account name and then click “Assign users or groups” in the top right.

Assigning permissions to groups makes it easier to manage organizational roles and audit access. Check our Admin group and click “Next”.

Here’s where we set the permissions this group can have in the selected accounts. Check the AdministratorAccess set we previously created and then click “Next”.

Finally, make sure everything looks good (three accounts, Admin group, AdministratorAccess permission set) and then click “Submit”. AWS takes a few seconds to apply these permission rules to each of the selected accounts then redirects you to the “AWS accounts” page.

Note that the permission sets have been applied to each account as expected.

Testing Sign In

We’ve successfully set up SSO for our AWS organization. To test it out, sign out of your current AWS session and go to your SSO portal link (myapp.awsapps.com/start/). Use the magic link from the user creation email to set your password if you haven’t already. Otherwise, visit the portal and enter your credentials.

You can see that the person signed in has access to three accounts - Dev, Prod, and Management - and can assume the AdministratorAccess role in all three. If this person was also part of a group with PowerUserAccess, you’d see both permission sets listed. People can only see the accounts and roles they have access to, so a contractor with PowerUserAccess in the Dev account would only see one role and one account. Clicking AdministratorAccess takes you to the AWS console in that account, signed in as a federated user.

This federated authentication works the same way for your local development environment through the AWS CLI.

AWS CLI Integration

The SSO setup extends to your local development environment through AWS CLI profiles. Configure your ~/.aws/config file with profiles for each account:

[profile st-prod-admin]
sso_session = st-allen
sso_account_id = { prod account id }
sso_role_name = AdministratorAccess
region = us-east-1
output = json

[profile st-dev-admin]
sso_session = st-allen
sso_account_id = { dev account id }
sso_role_name = AdministratorAccess
region = us-east-1
output = json

[sso-session st-allen]
sso_start_url = { your SSO portal URL }
sso_region = us-east-1

Replace the account IDs with your actual account numbers and update the SSO start URL to match your portal.

I like using these shell functions to streamline profile switching:

set_aws_profile_dev() {
    export AWS_PROFILE="st-dev-admin"
    aws sso login
    echo $AWS_PROFILE
}

set_aws_profile_prod() {
    export AWS_PROFILE="st-prod-admin"
    aws sso login
    echo $AWS_PROFILE
}

Now you can authenticate to any environment with temporary credentials in one command. For the Developement environment, we’d run

set_aws_profile_dev

Your application code automatically picks up these credentials through AWS SDKs’ built-in credential provider chain. Whether you’re using the aws cli or an SDK in your language of choice, the active profile will be picked up, using the temporary credentials without requiring any code changes.

These credentials automatically expire based on the session duration you configured in your permission set. Validate your authentication with:

aws sts get-caller-identity —no-cli-pager

This returns your UserId, Account, and Arn as JSON, confirming you’re authenticated as a federated user.

Wrapping Up and Next Steps

You’ve implemented Single Sign-On (SSO) to each of your AWS accounts for free using AWS Organizations. The deployment-encapsulating member accounts provide isolation per environment, IAM Identity Center handles SSO with temporary credentials, and your CLI is configured for secure local development.

This one-time effort creates a strong security posture that sets your company up for staffing flexibility and compliance while implementing best practices with short-lived, temporary credentials. As you scale, you can add more granular permission sets, integrate external identity providers, and onboard team members without restructuring your access controls.

Enjoyed this Article?