TylerBrock / saw

Fast, multi-purpose tool for AWS CloudWatch Logs
MIT License
1.4k stars 77 forks source link

Does not work with aws-okta or aws-vault #7

Closed argais closed 3 years ago

argais commented 6 years ago

These two tools allow you to save your credentials in the keychain instead of the plain text file in .aws/credentials, and they work just fine with other apps that use the aws go sdk.

But whenever I try to use saw with them I get:

➜ aws-okta exec myprofile -- saw groups
panic: SharedConfigAssumeRoleError: failed to load assume role for arn:aws:iam::REDACTED:role/secondary-role, source profile has no shared credentials

goroutine 1 [running]:
github.com/TylerBrock/saw/vendor/github.com/aws/aws-sdk-go/aws/session.Must(0x0, 0x156ea60, 0xc4200693b0, 0x0)
    /Users/tbrock/Code/Go/src/github.com/TylerBrock/saw/vendor/github.com/aws/aws-sdk-go/aws/session/session.go:274 +0x54
github.com/TylerBrock/saw/blade.NewBlade(0x17a8fc0, 0x17a8840, 0x0, 0x4)
    /Users/tbrock/Code/Go/src/github.com/TylerBrock/saw/blade/blade.go:49 +0x16a
github.com/TylerBrock/saw/cmd.glob..func3(0x17a3620, 0x17c6788, 0x0, 0x0)
    /Users/tbrock/Code/Go/src/github.com/TylerBrock/saw/cmd/groups.go:19 +0x46
github.com/TylerBrock/saw/vendor/github.com/spf13/cobra.(*Command).execute(0x17a3620, 0x17c6788, 0x0, 0x0, 0x17a3620, 0x17c6788)
    /Users/tbrock/Code/Go/src/github.com/TylerBrock/saw/vendor/github.com/spf13/cobra/command.go:766 +0x2c1
github.com/TylerBrock/saw/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0x17a3880, 0x0, 0x14edded, 0x23)
    /Users/tbrock/Code/Go/src/github.com/TylerBrock/saw/vendor/github.com/spf13/cobra/command.go:852 +0x30a
github.com/TylerBrock/saw/vendor/github.com/spf13/cobra.(*Command).Execute(0x17a3880, 0xc420147f78, 0xc42009c058)
    /Users/tbrock/Code/Go/src/github.com/TylerBrock/saw/vendor/github.com/spf13/cobra/command.go:800 +0x2b
main.main()
    /Users/tbrock/Code/Go/src/github.com/TylerBrock/saw/saw.go:10 +0x2d
exit status 2

Lemme know if I can provide any other info.

TylerBrock commented 6 years ago

Thanks for reporting this. I've never used aws-vault or okta so I apologize for it not working straight away. Shouldn't be too tough to figure out though.

argais commented 6 years ago

Cool. Lemme know if I can help testing.

Fernando Battistella

Sent from my iPhone

On Jul 17, 2018, at 1:05 PM, Tyler Brock notifications@github.com wrote:

Thanks for reporting this. I've never used aws-vault or okta so I apologize for it not working straight away. Shouldn't be too tough to figure out though.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

TylerBrock commented 6 years ago

Was just reading about this a bit, can you describe your configuration a little bit more?

In the aws-vault docs it says for you profile to assume a role your ~/.aws/config should look something like what they have here where read-only is the source profile and admin is the one having elevated privileges.

In your case I'd expect an entry for myprofile and one for secondary-role that references myprofile as the source. I'm new to aws-vault so forgive me if this is not on target but do you have something like that in your config?

argais commented 6 years ago

Yes, its exactly like they have in the link

[profile auth_or_bastion_account]
region=us-east-1

[profile admin]
mfa_serial = arn:aws:iam::123456789012:mfa/jonsmith
source_profile = auth_or_bastion_account
role_arn = arn:aws:iam::123456789012:role/admin-access

while profile admin can be also assuming a role in another account.

like in a project i am working right now, there is a main authentication only account, with an mfa, and from there you assume roles on the secondary accounts. most of the projects I'm working lately use something similar to this, as this implementation is now recommended by aws under their "landing zone" setup.

functionality wise, the only difference from a regular aws cli setup is that instead of saving the key/secret key in a text file, it saves on your macos keychain (or linux/windows similar). and when you call the profile it exposes the credentials it gets as env vars.

e.g. ➜ env | rg AWS AWS_HOME=/Users/fernando/.aws

➜ aws-vault exec company-sandbox -- env | rg AWS AWS_HOME=/Users/fernando/.aws AWS_VAULT=company-sandbox AWS_DEFAULT_REGION=ca-central-1 AWS_REGION=ca-central-1 AWS_ACCESS_KEY_ID=AAAAAAAAAAAAredactedofcourse AWS_SECRET_ACCESS_KEY= AAAAAAAAAAAAredactedofcourse AWS_SESSION_TOKEN=longassstring AWS_SECURITY_TOKEN=anotherlongassstring

hope this helps a bit :)

Cheers,

Fernando Battistella

On Jul 22, 2018, at 1:48 PM, Tyler Brock notifications@github.com wrote:

Was just reading about this a bit, can you describe your configuration a little bit more?

In the aws-vault docs it says for you profile to assume a role your ~/.aws/config should look something like what they have here https://github.com/99designs/aws-vault#assuming-roles where read-only is the source profile and admin is the one having elevated privileges.

In your case I'd expect an entry for myprofile and one for secondary-role that references myprofile as the source. I'm new to aws-vault so forgive me if this is not on target but do you have something like that in your config?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/TylerBrock/saw/issues/7#issuecomment-406884498, or mute the thread https://github.com/notifications/unsubscribe-auth/AIkdlNUIav_nl-kT_tRxL7ttrJPunjcSks5uJLrggaJpZM4VQZyU.

udondan commented 5 years ago

aws-okta works fine for me together with saw. Lil wrapper in my .bashrc and instantly worked.

function saw {
        aws-okta exec "myprofile" -- saw "$@"
}
arnuschky commented 5 years ago

Works fine for me with aws-vault. Nothing special, just

aws-vault exec <profile> -- saw ...