forked from Versent/saml2aws
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
5 changed files
with
85 additions
and
7 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -385,10 +385,65 @@ To use this credential, call the AWS CLI with the --profile option (e.g. aws --p | |
``` | ||
|
||
## Advanced Configuration | ||
### Windows Subsystem Linux (WSL) Configuration | ||
If you are using WSL1 or WSL2, you might get the following error when attempting to save the credentials into the keychain | ||
|
||
Configuring multiple accounts with custom role and profile in `~/.aws/config` with goal being isolation between infra code when deploying to these environments. This setup assumes you're using separate roles and probably AWS accounts for `dev` and `test` and is designed to help operations staff avoid accidentally deploying to the wrong AWS account in complex environments. Note that this method configures SAML authentication to each AWS account directly (in this case different AWS accounts). In the example below, separate authentication values are configured for AWS accounts 'profile=customer-dev/awsAccount=was 121234567890' and 'profile=customer-test/awsAccount=121234567891' | ||
``` | ||
No such interface “org.freedesktop.DBus.Properties” on object at path / | ||
``` | ||
|
||
This happens because the preferred keyring back-end - uses the `gnome-keyring` by default - which requires X11 - and if you are not using Windows 11 with support for Linux GUI applications - this can be difficult without [configuring a X11 forward](https://stackoverflow.com/questions/61110603/how-to-set-up-working-x11-forwarding-on-wsl2). | ||
|
||
There are 2 preferred approaches to workaround this issue: | ||
|
||
#### Option 1: Disable Keychain | ||
You can apply the `--disable-keychain` flag when using both the `configure` and `login` commands. Using this flag means that your credentials (such as your password to your IDP, or in the case of Okta the Okta Session Token) will not save to your keychain - and be skipped entierly. This means you will be required to enter your username and password each time you invoke the `login` command. | ||
|
||
#### Option 2: Configure Pass to be the default keyring | ||
There are a few steps involved with this option - however this option will save your credentials (such as your password to your IDP, and session tokens etc) into the `pass`[https://www.passwordstore.org/] keyring. The `pass` keyring is the standard Unix password manager. This option was *heavily inspired* by a similar issue in [aws-vault](https://github.com/99designs/aws-vault/issues/683) | ||
|
||
To configure pass to be the default keyring the following steps will need to be completed (assuming you are using Ubuntu 20.04 LTS): | ||
|
||
1. Install the pass backend and update gnupg, which encrypts passwords | ||
```bash | ||
sudo apt-get update && sudo apt-get install -y pass gnupg | ||
``` | ||
|
||
2. Generate a key with gpg (gnupg) and take note of your public key | ||
```bash | ||
gpg --gen-key | ||
``` | ||
|
||
### Dev Account Setup | ||
The output of the gpg command will output the something similar to the following: | ||
``` | ||
public and secret key created and signed. | ||
pub rsa3072 2021-04-22 [SC] [expires: 2023-04-22] | ||
844E426A53A64C2A916CBD1F522014D5FDBF6E3D | ||
uid Meir Gabay <[email protected]> | ||
sub rsa3072 2021-04-22 [E] [expires: 2023-04-22] | ||
``` | ||
|
||
3. Create a storage key in pass from the previously generated public (pub) key | ||
```bash | ||
pass init <GPG_PUBLIC_KEY> | ||
``` | ||
during the `init` process you'll be requested to enter the passphrase provided in step 2 | ||
|
||
4. Now, configure `saml2aws` to use the `pass` keyring. This can be done by setting the `SAML2AWS_KEYRING_BACKEND` environment variable to be `pass`. You'll need to also set the `GPG_TTY` to your current tty which means you can set the variable to `"$( tty )"` | ||
|
||
which means the following can be added into your profile | ||
``` | ||
export SAML2AWS_KEYRING_BACKEND=pass | ||
export GPG_TTY="$( tty )" | ||
``` | ||
|
||
5. Profit! Now when you run login/configure commands - you'll be promoted once to enter your passphrase - and your credentials will be saved into your keyring! | ||
|
||
|
||
### Configuring Multiple Accounts | ||
Configuring multiple accounts with custom role and profile in `~/.aws/config` with goal being isolation between infra code when deploying to these environments. This setup assumes you're using separate roles and probably AWS accounts for `dev` and `test` and is designed to help operations staff avoid accidentally deploying to the wrong AWS account in complex environments. Note that this method configures SAML authentication to each AWS account directly (in this case different AWS accounts). In the example below, separate authentication values are configured for AWS accounts 'profile=customer-dev/awsAccount=was 121234567890' and 'profile=customer-test/awsAccount=121234567891' | ||
#### Dev Account Setup | ||
|
||
To setup the dev account run the following and enter URL, username and password, and assign a standard role to be automatically selected on login. | ||
|
||
|
@@ -415,7 +470,7 @@ region = us-east-1 | |
|
||
To use this you will need to export `AWS_DEFAULT_PROFILE=customer-dev` environment variable to target `dev`. | ||
|
||
### Test Account Setup | ||
#### Test Account Setup | ||
|
||
To setup the test account run the following and enter URL, username and password. | ||
|
||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,12 +1,19 @@ | ||
package commands | ||
|
||
import ( | ||
"os" | ||
|
||
"github.com/versent/saml2aws/v2/helper/credentials" | ||
"github.com/versent/saml2aws/v2/helper/linuxkeyring" | ||
"github.com/versent/saml2aws/v2/pkg/cfg" | ||
) | ||
|
||
func init() { | ||
if keyringHelper, err := linuxkeyring.NewKeyringHelper(); err == nil { | ||
c := linuxkeyring.Configuration{ | ||
Backend: os.Getenv(cfg.KeyringBackEnvironmentVariableName), | ||
} | ||
|
||
if keyringHelper, err := linuxkeyring.NewKeyringHelper(c); err == nil { | ||
credentials.CurrentHelper = keyringHelper | ||
} | ||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters