Credentials

Right, so you’ve got a secret in one account and something in another account that desperately needs it. Welcome to the multi-account reality, where we wall things off for security and then immediately have to poke a bunch of carefully controlled holes in those walls to get anything done. It’s the cloud’s version of “we need to have a talk” with your infrastructure. The first thing to get straight is that neither Secrets Manager nor Parameter Store has a magical “replicate this to Timbuktu” button. AWS would love to sell you a solution that involves Step Functions, EventBridge, Lambda, and a few dozen IAM roles (and honestly, it’s not a terrible idea for complex setups), but for most of us, the goal is something simpler, more robust, and less likely to fail in a way that requires a 3 AM page.

Right, let’s get your code talking to the vault. Because hardcoding secrets is for amateurs and hello-world tutorials, and you’re neither. Whether you’re in a serverless Lambda, a container in ECS, or on a crusty old EC2 instance, the principle is the same: your code needs permission to ask for the secret, and then it needs to know how to ask. I’ll show you the patterns, and then we’ll gripe about the weird bits.

Right, let’s talk about SecureString parameters. This is the part where I have to give you some good news and some bad news. The good news is that they are a way to store secrets directly in Parameter Store, encrypted at rest by a KMS key. The bad news? AWS themselves will tell you they are basically a legacy feature at this point, and you should probably be using Secrets Manager instead. But since you’re here, and because you’ll inevitably run into them in the wild (or in a legacy system you’ve inherited), we need to dig in.

Alright, let’s talk about the two flavors of SSM Parameter Store: Standard and Advanced. Think of them as the difference between a reliable, no-frills sedan and a souped-up performance model with all the bells and whistles. One gets you from A to B just fine for most trips, while the other is for when you’re hauling something sensitive or need to go really, really fast. The core distinction boils down to three things: storage size, cost, and advanced features. Let’s cut through the marketing-speak.

Alright, let’s cut through the marketing fluff and get to the brass tacks. You’ve got secrets and configuration data. AWS gives you two main vaults to put them in: Secrets Manager and the SSM Parameter Store. They look similar on the surface—both hold strings you don’t want hardcoded—but the devil, and your bill, is in the details. Choosing the wrong one is like using a diamond-tipped drill to hang a picture frame; it’ll work, but your accountant will weep.

Right, let’s talk about automatic rotation. You’ve got a database credential in Secrets Manager, and you’re not a masochist, so you’d rather not manually change this password every 90 days. Good call. The magic wand here is a Lambda function that Secrets Manager will invoke for you on a schedule to handle the whole tedious process. But here’s the thing you need to internalize right now: you are responsible for writing most of that magic. AWS provides the framework and the invocation; you provide the logic. It’s a partnership, and like most partnerships, it works great until you forget an important detail.

Alright, let’s talk about Secrets Manager, the service that finally lets you stop committing database passwords to your GitHub repo where they’ll live forever, mocked by Russian bots. This isn’t just a secure locker for your most sensitive data; it’s a full-blown credential management system with a party trick: automatic rotation. It’s for the stuff that would cause a real, “oh we’re on the news” level of disaster if it leaked: database credentials, API keys (especially the ones that cost money), and OAuth tokens.

Right, let’s get your tools sharpened. Setting up the AWS CLI is like getting a master key to the entire AWS kingdom. It’s the no-nonsense, text-based way to tell AWS what to do, and it doesn’t care if you’re in a GUI mood or not. We’re going to set it up properly so it doesn’t come back to bite you later. First, the installation. You’re not downloading some sketchy .exe from a random website. You’ll use pip, Python’s package manager. Yes, it’s written in Python. No, you don’t need to know Python. The irony is not lost on me.

Alright, let’s get your Python environment ready to boss AWS around. We’re going to talk about boto3, which is the official AWS SDK for Python. It’s the tool you’ll use to make AWS do your bidding programmatically. Forget the web console; you’re a programmer now. The goal is to write code that creates, destroys, and manages infrastructure. It’s like playing god, but with more error handling. First things first, get it installed. It’s not in the standard library, so pip is your friend.

Right, let’s talk about aws configure sso. This is the command that saves you from the dark ages of managing IAM user access keys, which are basically a permanent security liability you have to stash somewhere safe. With AWS SSO, you log in once through a pretty portal, get temporary, scoped-down credentials, and the CLI handles the rest. It’s a vastly more secure and manageable way to do things. The first time you run it, it feels a bit like magic. The second time, you’ll wonder why all cloud auth isn’t this (relatively) sane.

Right, let’s talk about the part of this process that everyone loves to hate: environment variables. We’re going to set them up so you don’t have to type your credentials every single time you want to list an S3 bucket, which is, I assure you, a fate worse than death. Think of environment variables as the sticky notes you leave for your computer. “Hey computer, here’s my secret key. Don’t show it to anyone, and use it when I ask you to do AWS stuff.” It’s a simple, effective, and tragically easy-to-mess-up system.

Right, let’s talk about the single most important tool for not accidentally deploying your resume to your production environment: named profiles. You’ve probably already used the default profile. You ran aws configure, shoved in your keys, and off you went. That’s fine for a single account, like your personal sandbox. But the moment you have more than one AWS account (and you will, because this is AWS and they give them out like candy), using the default profile is a one-way ticket to “oh god why is my production database in us-east-1 now?”

Right, let’s get you set up so you can actually do things with AWS instead of just staring at the login page. This is where we move from being a tourist to a resident. The CLI and SDKs are your primary tools, and they all have one thing in common: they need to know who you are. They do this using credentials. Let’s demystify how you give them those credentials without accidentally uploading your secret access key to a public GitHub repo (a classic rookie move, we’ve all had that heart-stopping moment).

Alright, let’s get you set up with the modern toolbelt. The AWS CLI v2 is a massive improvement over its predecessor—faster, handles IAM roles better, and doesn’t require a separate Python installation. We’re going to do this the right way, which means avoiding the OS package managers (apt, yum, brew) like the plague for this particular install. Their packages are often horrifically out of date, and wrestling with a three-year-old CLI version is a special kind of hell I won’t subject you to. We’re going straight to the source.