AWS Cli List-profiles
You run the aws cli list profiles command to view all saved cloud accounts on your machine. The tool reads your local settings files and prints each profile name on your screen. Engineering teams set up multiple profiles to switch between test and live cloud accounts. When these local profiles hold broad permissions, one mistake can break live systems. How the aws cli list profiles workflow operates The command line tool stores account details in two plain text files on your disk. Both files
AWS IAM Policies + CLI Authentication Patterns: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You run the aws cli list profiles command to view all saved cloud accounts on your machine. The tool reads your local settings files and prints each profile name on your screen. Engineering teams set up multiple profiles to switch between test and live cloud accounts. When these local profiles hold broad permissions, one mistake can break live systems.
How the aws cli list profiles workflow operates
The command line tool stores account details in two plain text files on your disk. Both files sit inside a hidden folder in your user home directory. One file holds basic settings like your default region and output format. The other file stores secret keys and session tokens for each named role.
When you ask the tool to list your profiles, it scans both local files. It merges the names it finds and removes any duplicates before showing the final list. The tool does not call the cloud network during this step. It only reads what is written on your hard drive right now.
Teams often map each profile to a specific cloud role or account. A developer might have one profile for daily testing and another for production fixes. To run a command, the user picks a profile name or sets an environment variable. The tool then grabs the matching keys and sends the request to the cloud.
What local profiles solve and the gaps they leave
Named profiles make it easy for one person to work across many cloud accounts. You do not need to copy and paste secret keys every time you switch tasks. You can also link profiles to single sign-on tools so keys rotate more often. This setup keeps daily work fast for engineers who manage large cloud estates.
Still, local profile files leave major operational gaps for security teams. First, secret keys sit in plain text files on every developer laptop. If malware hits a laptop, an attacker can read every profile file right away. Even temporary session tokens stay active on disk until their timer runs out.
AWS IAM Policies + CLI Authentication Patterns: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Second, a profile only decides who can log in at the start of a session. Once the user is in, the profile cannot inspect what individual commands do in flight. A developer who forgets which profile is active might run a destructive command in production. Native profile setups also cannot mask sensitive fields like emails or card numbers in command outputs.
Managing cloud roles at scale
As teams grow, keeping local profile files in sync becomes a slow chore. New engineers copy sample files from teammates and often keep old roles they do not need. When an engineer changes teams, their laptop still holds profile names for their old projects. Auditing what is stored on hundreds of laptops is almost impossible for security staff.
To reduce risk, teams should move away from static keys stored on user machines. Cloud roles should grant only the minimum permissions needed for a specific task. Teams also need clear visibility into every command that runs against live cloud accounts. Controlling commands at runtime stops bad actions before they harm production data.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Why is a saved profile missing from my list output?
The tool checks two separate files and requires matching header formats in each one. If you misspell the section header in the settings file, the profile will not show up.
Does listing profiles check if my keys are still valid?
No, the list command only reads text names from your local hard drive. It does not contact the cloud to verify if your keys or tokens still work.
Where does the tool look for profile files by default?
It looks inside a hidden cloud folder located in your main user directory. You can change this file path by setting custom environment variables in your shell.