gimme aws creds
v2.8.2
gimme-aws-creds est une CLI qui utilise un IdP Okta via SAML pour acquérir des informations d'identification AWS temporaires via AWS STS.
Okta est un fournisseur d'identité (IdP) SAML qui peut être facilement configuré pour effectuer le SSO sur votre console AWS. Okta propose un outil CLI OSS Java pour obtenir des informations d'identification AWS temporaires, mais j'ai trouvé qu'il nécessite plus d'informations que l'utilisateur moyen d'Okta n'en aurait et ne s'adapte pas bien s'il possède plus d'une application Okta.
Avec gimme-aws-creds, tout ce que vous devez savoir est votre nom d'utilisateur, votre mot de passe, votre URL Okta et votre jeton MFA, si MFA est activé. gimme-aws-creds vous offre la possibilité de sélectionner l'application et le rôle Okta AWS pour lesquels vous souhaitez obtenir des informations d'identification. Vous pouvez également préconfigurer l'application et le nom du rôle en passant -c ou en modifiant le fichier de configuration. Tout cela est couvert dans la section utilisation.
Okta est une marque déposée d'Okta, Inc. et cet outil n'a aucune affiliation ni parrainage par Okta, Inc.
Intégration d'Okta SAML à AWS à l'aide de l'application AWS
Python3.7+
gimme-aws-creds dépend de la bibliothèque ctap-keyring-device pour la prise en charge de WebAuthn. Toutes les versions publiées de ctap-keyring-device nécessitent winRT sous Windows, qui ne fonctionne que sur Python 3.9 et versions antérieures et n'est plus maintenu. Jusqu'à ce qu'une version de ctap-keyring-device prenant en charge winSDK (le remplacement de winRT) soit publiée sur PyPi, ou qu'une autre solution soit trouvée, la prise en charge de WebAuthn ne sera pas disponible pour les personnes exécutant Python 3.10+ sous Windows.
Gimme-creds-lambda peut être utilisé comme proxy pour les API Okta nécessaires à gimme-aws-creds. Cela supprime l’exigence d’une clé API Okta. Gimme-aws-creds s'authentifie auprès de gimme-creds-lambda à l'aide d'OpenID Connect et le lambda gère toutes les interactions avec les API Okta. Vous pouvez également définir la variable d'environnement OKTA_API_KEY et la valeur de configuration gimme_creds_server sur « interne » pour appeler les API Okta directement depuis gimme-aws-creds.
Il s'agit d'un projet Python 3.
Installer/mettre à niveau depuis PyPi :
pip3 install --upgrade gimme-aws-credsOU
Installez/mettez à niveau le dernier package gimme-aws-creds directement depuis GitHub :
pip3 install --upgrade git+git://github.com/Nike-Inc/gimme-aws-creds.gitOU
Installez le package gimme-aws-creds si vous avez déjà cloné la source :
python -m pip install .OU
Utiliser un homebrew
brew install gimme-aws-credsOU
Utiliser avec les flocons nix
# flake.nix
# Use by running `nix develop`
{
description = " Shell example " ;
inputs.flake-utils.url = " github:numtide/flake-utils " ;
inputs.nixpkgs.url = " github:nixos/nixpkgs/nixos-unstable " ;
inputs.gimme-aws-creds.url = " github:Nike-Inc/gimme-aws-creds " ;
outputs = {
self,
nixpkgs,
flake-utils,
gimme-aws-creds,
...
} @ inputs:
flake-utils.lib.eachDefaultSystem
(
system: let
pkgs = nixpkgs.legacyPackages. ${system} ;
in {
devShells.default = pkgs.mkShell {
packages = [pkgs.bash gimme-aws-creds.defaultPackage. ${system} ] ;
} ;
}
) ;
}OU
Utiliser avec nix original
# shell.nix
# Use by running `nix-shell`
{pkgs ? import < nixpkgs > {}, ...}:
with pkgs ; let
gimme-src = fetchgit {
name = " gimme-aws-creds " ;
url = " https://github.com/Nike-Inc/gimme-aws-creds " ;
branchName = " master " ;
sha256 = " " ; # nix-prefetch-url --unpack https://github.com/Nike-Inc/gimme-aws-creds/archive/master.tar.gz
} ;
gimme-aws-creds = import gimme-src ;
in
mkShell rec {
name = " gimme-aws-creds " ;
buildInputs = [
bash
(gimme-aws-creds.default)
] ;
}OU
Créez l'image Docker localement :
docker build -t gimme-aws-creds .Pour faciliter les choses, vous pouvez également créer un alias pour la commande gimme-aws-creds avec docker :
# make sure you have the "~/.okta_aws_login_config" locally first!
touch ~ /.okta_aws_login_config &&
alias gimme-aws-creds= " docker run -it --rm
-v ~/.aws/credentials:/root/.aws/credentials
-v ~/.okta_aws_login_config:/root/.okta_aws_login_config
gimme-aws-creds "Avec cette configuration, vous pourrez exécuter d’autres commandes de manière transparente !
Si vous utilisez Bash ou Zsh, vous pouvez ajouter la saisie semi-automatique pour les options de ligne de commande et les noms de profil gimme-aws-creds. Pour ajouter la configuration de saisie semi-automatique, ajoutez ce qui suit à la fin de votre .bashrc ou .zshrc :
.bashrc
INSTALL_DIR= $( dirname $( which gimme-aws-creds ) )
source ${INSTALL_DIR} /gimme-aws-creds-autocomplete.sh ".zshrc
INSTALL_DIR= $( dirname $( which gimme-aws-creds ) )
autoload bashcompinit
bashcompinit
source ${INSTALL_DIR} /gimme-aws-creds-autocomplete.shIl existe deux options pour utiliser gimme-aws-creds avec un domaine OIE :
Il s'agit de la méthode recommandée pour l'authentification auprès de l'OIE. Il correspond au flux utilisé par le client AWS d'Okta. Lorsque vous utilisez gimme-aws-creds avec le flux d'autorisation de périphérique, vous vous authentifierez à l'aide de votre navigateur. Stocker les informations d'identification dans le trousseau ou transmettre les codes MFA via la ligne de commande n'est PAS POSSIBLE.
Pour utiliser gimme-aws-creds avec un domaine Okta Identity Engine (OIE), vous devez créer une nouvelle application native OIDC et la connecter à votre ou vos applications d'intégration AWS.
L'application native OIDC nécessite Authorization Code de types d'octroi, Device Authorization et Token Exchange . Ces paramètres se trouvent dans l'interface utilisateur d'administration d'Okta dans Applications > [the OIDC app] > General Settings > Grant type .
Le couplage avec l'application AWS Federation est réalisé dans les paramètres de connexion de l'application Fed. Ces paramètres se trouvent dans l'interface utilisateur d'administration Okta dans Applications > [the AWS Fed app] > Sign On . Assurez-vous de définir la valeur Allowed Web SSO Client sur l'ID client de l'application native OIDC. Répétez ce paramètre pour chaque application AWS à laquelle vous souhaitez accéder avec gimme-aws-creds.
Enfin, définissez l'ID client dans gimme-aws-creds ( gimme-aws-creds --action-configure ou mettez à jour le paramètre client_id dans votre fichier de configuration)
Assurez-vous d'utiliser la même stratégie d'authentification pour l'application AWS Federation et l'application OIDC (ou au moins utilisez des règles de stratégie équivalentes pour les deux). Sinon, vous recevrez une réponse 400 Bad Request lors de la demande du jeton Web SSO.
Le flux de connexion utilisé dans Okta Classic fonctionne toujours avec les domaines Okta Identity Engine, MAIS il y a quelques mises en garde :
stateToken lors de la demande d'authentification « intensifiée ». Cette fonctionnalité a été supprimée dans l'OIE, donc si la politique d'authentification de vos applications AWS nécessite une MFA mais pas la politique de session globale (ou si un niveau plus élevé de facteur MFA est requis pour accéder à AWS), vous ne pouvez pas vous authentifier à l'aide de la méthode classique. flux de connexion.Pour configurer l'exécution de la configuration :
gimme-aws-creds --action-configureVous pouvez également configurer différents profils de configuration Okta, ce qui est utile si vous disposez de plusieurs comptes ou environnements Okta pour lesquels vous avez besoin d'informations d'identification. Vous pouvez utiliser l'assistant de configuration ou exécuter :
gimme-aws-creds --action-configure --profile profileName Un assistant de configuration vous demandera de saisir les paramètres de configuration nécessaires à l'exécution de l'outil, le seul requis est le okta_org_url . Le fichier de configuration est écrit dans ~/.okta_aws_login_config , mais vous pouvez modifier l'emplacement avec la variable d'environnement OKTA_CONFIG .
https://companyname.okta.com .OKTA_API_KEY requise)~/.aws/credentials sinon elles seront écrites sur la sortie standard.role de mot réservé utilisera le composant de nom du rôle arn comme nom de profil. c'est-à-dire arn:aws:iam::123456789012:role/okta-1234-role devient la section [okta-1234-role] dans le fichier d'informations d'identification AWSacc utilisera le numéro de compte (ou l'alias si resolve_aws_alias est défini sur y) comme nom de profil. c'est-à-dire que arn:aws:iam::123456789012:role/okta-1234-role devient la section [arn:aws:iam::123456789012] ou si resolve_aws_alias [okta-1234-role] dans le fichier d'informations d'identification aws.acc-role utilisera le composant de nom du rôle arn précédé du numéro de compte (ou de l'alias si resolve_aws_alias est défini sur y) pour éviter les collisions, c'est-à-dire arn:aws:iam::123456789012:role/okta-1234-role devient la section [123456789012-okta-1234-role], ou si resolve_aws_alias [okta-1234-role] dans le fichier d'informations d'identification AWSdefault , les crédits temporaires seront stockés dans le profil par défaut.default est sélectionnée, elle sera écrasée plusieurs fois et le dernier rôle l'emportera. La même chose se produit lorsque role est sélectionné et que vous disposez de plusieurs comptes avec les mêmes noms de rôle. Pensez à utiliser acc-role si cela se produit.OKTA_MFA_CODE ou --mfa-code s'il est défini, ou demande à l'utilisateur un mot de passe (OTP).Duo Push (par défaut)PasscodePhone Call-r ou --resolvey : -/some/path/administrator n : -administrator -m ou --remember-devicejson , export ou windows , détermine le format de sortie des informations d'identification par défaut, peut également être spécifié par --output-format FORMAT et -o FORMAT .Le fichier de configuration suit un format de fichier de configuration. Par défaut, il se trouve dans $HOME/.okta_aws_login_config
Exemple de fichier :
[myprofile]
client_id = myclient_idLes configurations peuvent hériter d'autres configurations pour partager des paramètres de configuration communs.
[my-base-profile]
client_id = myclient_id
[myprofile]
inherits = my-base-profile
aws_rolename = my-roleSi vous n'utilisez pas gimme-creds-lambda ni les paramètres appurl, assurez-vous de définir la variable d'environnement OKTA_API_KEY.
Après avoir exécuté --action-configure, exécutez simplement gimme-aws-creds. Vous serez invité à fournir les informations nécessaires.
$ ./gimme-aws-creds
Username: [email protected]
Password for [email protected]:
Authentication Success ! Calling Gimme-Creds Server...
Pick an app:
[ 0 ] AWS Test Account
[ 1 ] AWS Prod Account
Selection: 1
Pick a role:
[ 0 ]: OktaAWSAdminRole
[ 1 ]: OktaAWSReadOnlyRole
Selection: 1
Multi-factor Authentication required.
Pick a factor:
[ 0 ] Okta Verify App: SmartPhone_IPhone: iPhone
[ 1 ] token:software:totp: [email protected]
Selection: 0
Okta Verify push sent...
export AWS_ACCESS_KEY_ID=AQWERTYUIOP
export AWS_SECRET_ACCESS_KEY=T ! # $JFLOJlsoddop1029405-P Vous pouvez automatiser la création des variables d'environnement en exécutant $(gimme-aws-creds) sous Linux ou gimme-aws-creds | iex en utilisant Windows Powershell
Vous pouvez exécuter un profil de configuration spécifique avec le paramètre --profile :
./gimme-aws-creds --profile profileName Le nom d'utilisateur et le mot de passe qui vous sont demandés sont ceux avec lesquels vous vous connectez à Okta. Vous pouvez prédéfinir votre nom d'utilisateur en définissant la variable d'environnement OKTA_USERNAME ou en utilisant le paramètre -u username .
Si vous n'avez pas configuré d'application ou de rôle Okta, vous serez invité à en sélectionner un.
Si tout se passe bien, vous obtiendrez votre accès AWS temporaire, votre clé secrète et votre jeton, ceux-ci seront soit écrits sur stdout, soit ~/.aws/credentials .
Vous pouvez toujours exécuter gimme-aws-creds --help pour toutes les options disponibles.
Alternativement, vous pouvez remplacer les valeurs de la section de configuration par des variables d'environnement dans les cas où, par exemple, vous souhaiterez peut-être modifier la durée de votre jeton. Une liste de valeurs à modifier avec les variables d'environnement est :
AWS_DEFAULT_DURATION - correspond à la configuration aws_default_durationAWS_SHARED_CREDENTIALS_FILE - fichier dans lequel écrire les informations d'identification, pointe vers ~/.aws/credentials par défautGIMME_AWS_CREDS_CLIENT_ID - correspond à la configuration client_idGIMME_AWS_CREDS_CRED_PROFILE - correspond à la configuration cred_profileGIMME_AWS_CREDS_OUTPUT_FORMAT - correspond à la configuration output_format et à l'option CLI --output-formatOKTA_AUTH_SERVER - correspond à la configuration okta_auth_serverOKTA_DEVICE_TOKEN - correspond à la configuration device_token , peut être utilisé dans CIOKTA_MFA_CODE - correspond à l'option CLI --mfa-codeOKTA_PASSWORD - fournit un mot de passe lors de l'authentification, peut être utilisé dans CIOKTA_USERNAME - correspond à la configuration okta_username et à l'option CLI --usernameAWS_STS_REGION - force l'utilisation du STS dans une région spécifique ( us-east-1 , eu-north-1 , etc.) Exemple : GIMME_AWS_CREDS_CLIENT_ID='foobar' AWS_DEFAULT_DURATION=12345 gimme-aws-creds
Pour modifier des variables en dehors de cela, vous devrez créer un profil distinct avec gimme-aws-creds --action-configure --profile profileName
gimme-aws-creds --action-list-profiles accédera à votre fichier de configuration Okta et imprimera tous les profils créés et leurs paramètres.
gimme-aws-creds --action-list-roles imprimera tous les rôles disponibles sur STDOUT sans récupérer leurs informations d'identification.
L'écriture dans le fichier d'informations d'identification AWS inclura la valeur x_security_token_expires au format RFC3339. Cela permet aux outils de valider si les informations d'identification expirent ou expirent bientôt et d'avertir l'utilisateur ou de déclencher une actualisation.
gimme-aws-creds -o json imprimera les informations d'identification au format JSON - 1 entrée par ligne
gimme-aws-creds --action-store-json-creds stockera les informations d'identification au format JSON de stdin vers le fichier d'informations d'identification aws, par exemple : gimme-aws-creds -o json | gimme-aws-creds --action-store-json-creds . Les données peuvent être modifiées par des scripts en cours de route.
La configuration et les interactions peuvent être configurées à l'aide de gimme_aws_creds.ui , les interfaces utilisateur prennent en charge toutes sortes d'interactions au sein de la bibliothèque, notamment : demander une entrée, les remplacements sys.argv et os.environ .
import sys
import gimme_aws_creds . main
import gimme_aws_creds . ui
account_ids = sys . argv [ 1 :] or [
'123456789012' ,
'120123456789' ,
]
pattern = "|" . join ( sorted ( set ( account_ids )))
pattern = '/:({}):/' . format ( pattern )
ui = gimme_aws_creds . ui . CLIUserInterface ( argv = [ sys . argv [ 0 ], '--roles' , pattern ])
creds = gimme_aws_creds . main . GimmeAWSCreds ( ui = ui )
# Print out all selected roles:
for role in creds . aws_selected_roles :
print ( role )
# Generate credentials overriding profile name with `okta-`
for data in creds . iter_selected_aws_credentials ():
arn = data [ 'role' ][ 'arn' ]
account_id = None
for piece in arn . split ( ':' ):
if len ( piece ) == 12 and piece . isdigit ():
account_id = piece
break
if account_id is None :
raise ValueError ( "Didn't find aws_account_id (12 digits) in {}" . format ( arn ))
data [ 'profile' ][ 'name' ] = 'okta-{}' . format ( account_id )
creds . write_aws_creds_from_data ( data )gimme-aws-creds fonctionne à la fois sur l'organisation compatible FIDO1 et sur l'organisation compatible WebAuthN
Notez que FIDO1 sera probablement obsolète dans un avenir proche à mesure que les normes évoluent vers WebAuthN.
La prise en charge de WebAuthN est disponible pour les clés de sécurité USB (gimme-aws-creds s'appuie sur la bibliothèque yubico fido2).
Pour utiliser votre ordinateur local comme authentifiant, avec Touch ID ou Windows Hello, si disponible, vous devez enregistrer un nouvel authentificateur via gimme-aws-creds, en utilisant :
gimme-aws-creds --action-setup-fido-authenticatorEnsuite, vous pouvez choisir l'authentificateur nouvellement enregistré dans la liste des facteurs.
Vous pouvez exécuter tous les tests unitaires en utilisant pytest. La plupart des tests sont simulés.
pytest -vv testsCe projet est maintenu par Eric Pierce
Je suis tombé sur okta_aws_login écrit par Joe Keegan, alors que je cherchais un outil CLI qui génère des jetons AWS via Okta. Malheureusement, il n'a pas été mis à jour depuis 2015 et ne semble pas fonctionner avec la version actuelle d'Okta. Mais il y avait encore du code génial que j'ai pu réutiliser sous la licence MIT pour me donner des crédits. J'ai noté dans les commentaires où j'ai utilisé son code, pour m'assurer qu'il reçoive le crédit approprié.
octa-aws-cli
okta-aws-cli-assumer-le-rôle
AWS - Comment implémenter l'accès API et CLI fédéré à l'aide de SAML 2.0 et AD FS
Gimme AWS Creds est publié sous la licence Apache, version 2.0
