Comments (13)
If your code really requires ~/.aws/credentials then it is broken and should be using the AWS SDK. Assuming your code is not actively broken, then it should support the profile config in ~/.aws/config which is generated thusly:
https://synfinatic.github.io/aws-sso-cli/commands/#config-profiles
from aws-sso-cli.
In our case, we are running inside a docker container, so ~/.aws/credentials
is the easiest vehicle to populate the credentials for multiple profiles that we use in Terraform. We specify the profile in our terraform setup to handle multiple environments (for example, state is globally stored in the root environment, RDS has to talk to both the current and root environment to delegate DNS, etc)
Additionally, I'm confused by
If your code really requires ~/.aws/credentials then it is broken
given aws documents its usage here. Can you help me understand a better workflow than using ~/.aws/credentials
? Could we authenticate aws-sso-cli
and then use the profile config you describe?
from aws-sso-cli.
AWS SSO credentials are temporary. Credentials in ~/.aws/credentials
are for static credentials. I don't support putting temporary credentials where static credentials go, because that prevents them from being rotated/updated as required. Also, the point of aws-sso
is to be more secure than placing your secrets in clear text files.
Terraform doesn't require using ~/.aws/credentials
because it uses the AWS Go SDK.
Honestly, it seems like what you really want to be doing is just using a single IAM Role/Permission Set that your user assumes. Then pass those IAM credentials into the docker container via environment variables. Then configure your terraform to use iam:AssumeRole to switch to the other accounts.
Alternatively, do as I originally suggested and make sure to add the aws-sso
binary to the docker container.
from aws-sso-cli.
Ah, I'm tracking now. What I was missing was the static vs. temporary nature of ~/.aws/credentials
. I'm good now
from aws-sso-cli.
OK, reopening this because installing within the docker container led to more questions/observations. Given Leapp is shutting down, this would be ideal for a replacement for our workflows that depended on it.
- I'd like to recommend that the
config-profiles
feature NOT include the-u open
in the~/.aws/config
. For a headless system, I changed theUrlAction
toprint
but after authentication, it was changing it back toopen
in the~/.aws/config
. - From an implementation perspective, I'm thinking the best solution is to copy the
~/.aws-sso/config.yaml
into the container like this (/localhost
is mapped to my$HOME
in the container):
mkdir ~/.aws-sso
sed 's/open/print/g' /localhost/.aws-sso/config.yaml >~/.aws-sso/config.yaml
- Looks like I'll need some way of handling secrets. In your research, is there anything headless/docker friendly we could use inside a container? Otherwise it prompts for a password every time you access
aws-sso
:
🐋 PSG/Geodesic [Docker] bsh ❯ aws-sso
Enter passphrase to unlock "/conf/.aws-sso/secure":
Verify this code in your browser: RXST-WVKS
Please open the following URL in your browser:
https://device.sso.us-east-2.amazonaws.com/?user_code=RXST-WVKS
The following changes are proposed to /localhost/.aws/config:
--- /localhost/.aws/config
+++ /localhost/.aws/config.new
@@ -1,35 +1,27 @@
# BEGIN_AWS_SSO_CLI
...
# END_AWS_SSO_CLI
Modify /localhost/.aws/config with proposed changes?: No
List of AWS roles for SSO Instance: pinnacle [Expires in: 7h 57m]
AccountIdPad | AccountAlias | RoleName | Profile | Expires
===================================================================================================================
...
mcrowe in infrastructure on remove-qbwc [#] with infrastructure took 2m30s
🐋 PSG/Geodesic [Docker] bsh ❯ aws-sso-profile pinnEnter passphrase to unlock "/conf/.aws-sso/secure": acle-dev
from aws-sso-cli.
So looking deeper into this...
Fundamentally, the only way to use multiple IAM roles/profiles directly with Terraform is going to be via ~/.aws/credentials
. There is a strong design pattern with AWS that a process/service should be granted a single IAM Role, and so that ties our hands. (EC2 and ECS metadata services for example both enforce this.) The exception for this is for you to use IAM role chaining which TF supports, but I'm assuming you've decided not to do for various reasons? The big advantage of using EC2/ECS/etc is that AWS auto-rotates the IAM credentials for you before they expire and they are always valid- for the life of the instance/container.
So with that in mind, the best solution right now I can think of really is basically what you did in your shell script by calling aws-sso eval
and writing to a file which you then copy to your container as ~/.aws/credentials
. Yes, the credentials will not auto-refresh when they expire. Not sure how long your TF apply is taking but you can increase your IAM credential lifetime up to a maximum of 12hrs.
In theory, you could gain a bit more time (hours) by utilizing the JSON secure store. You'd then authenticate via your SSO provider, copy the JSON store + config.yaml
to the container and use the credential_process
trick. Then as long as your SSO session has not expired, it will automatically refresh the IAM credentials. That said, your SSO session timer may or may not be longer than the IAM credential timer, so this might not really help.
To answer your other question... there is no "refresh all IAM tokens" option, but you can run aws-sso flush
and then fetch new tokens via aws-sso eval
. Of course, that only works if you have a valid SSO token/have previously logged in.
Anyways, due to the 2nd SSO timer, I'm not really sure how I can meaningfully improve your situation.
from aws-sso-cli.
Actually, I have a working prototype using the credential_process
! Turns out later versions of terraform support this, but after installing aws-sso-cli
in docker, I had to jump thru some hoops. Here's how I advertised it:
I am interested in your opinion of this section:
aws-sso --no-config-check
for f in PROFILE1 PROFILE2 PROFILE3; do
SHELL=/bin/bash aws-sso -L error --no-config-check eval -p $f > /dev/null
done
aws-sso list
From what I've been able to gleen:
- First
aws-sso
(no params) prompts the browser to authenticate - The
aws-sso eval
in the loop actually retrieves creds for each profile. When I didn't have this, I was getting expired permission issues - This simply shows all the statuses and isn't required
from aws-sso-cli.
- I honestly don't understand what the context is for those commands. They're mostly right I guess?
- You could use the
file
/ gpg based encryption + gpg-agent and have an obviously much more secure solution at the cost of complexity. - Frankly, I'd just write the credentials out to the
~/.aws/credentials
file and skip the use ofcredential_process
if you're just going to usejson
since it is less complicated and will result in faster performance. - Not sure I understand why you have to iterate over the profile(s) to get past the "expired permission issue" or what that is referring to.
Anyways, I don't use geodesic so I'm glad you got it to work. If it meets your needs I guess that's good enough. If someone from the geodesic team is looking to collaborate, I'm here.
from aws-sso-cli.
OK, sorry, in my head this made perfect sense. Let me step back and give some context:
- We use CloudPosse's geodesic to bundle all our terraform dev tools into a docker container.
- The
~/.aws
folder is symlink'd inside the docker container - Previously, we used Leapp to manage our credentials. When authenticating with multiple AWS profiles, Leapp uses
~/.aws/credentials
to store the creds - My goal is to determine a way to use aws-sso-cli inside a docker container with as little friction as possible
So, with that background, my design is essentially:
- Copy the
~/.aws-sso/config.yaml
into the container, - Replace
open
withprint
- Changing
SecureStore
toJson
I tried to find something keyring compatible that would work inside docker (such as your gpg suggestion), but I finally gave up. The interim creds are stored inside the container, so when we exit the container, the startup script removes it. It's not ultra secure, but good enough in our case. Not every user uses gpg -- I considered initializing it locally inside, but didn't really spend any time on it.
Regarding:
Not sure I understand why you have to iterate over the profile(s) to get past the "expired permission issue" or what that is referring to.
You were right, I don't. Must have been operator error
from aws-sso-cli.
When you say "~/.aws" is symlinked, you mean the files are copied at image build time or you are mounting it as a volume?
from aws-sso-cli.
from aws-sso-cli.
LMK if you want me to add this to the documentation somehow
from aws-sso-cli.
Honestly, no. The use ofjson
as the SecureStore is not something I would ever advocate anyone use. I honestly consider it a bug that it is documented so anyone but me knows it exists.
from aws-sso-cli.
Related Issues (20)
- Backport v2 improvements to v1 HOT 1
- Let's Encrypt for ECS Server HOT 2
- Improve management of CA/Cert for ECS Server
- `aws-sso cache` does not remove roles I no longer have access to
- generate `~/.aws/config` for ecs server endpoint
- Only auto update `~/.aws/config` for login/cache command
- Replace `config` with `setup`
- remove `static` code
- Warnings for missing access to accounts present in config HOT 2
- Version mkdocs documentation
- Change default profile format to friendly
- replace logrus with slog
- Honor $XDG_CONFIG_HOME
- aws-sso time fails HOT 1
- Default container for SSO Device Flow HOT 4
- Add `DefaultRegion` to `aws-sso config` configuration wizard HOT 1
- Add support for xonsh HOT 1
- Allow to update credentials of Default profile HOT 17
- Firefox Performs Search Instead of Opening in Container Tab HOT 1
- Windows WSL needs to default to `SecureStore: file` HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from aws-sso-cli.