ERREUR 1045 (28000) : Accès refusé pour l'utilisateur 'db_user'@'ip' (utilisant le mot de passe : YES) lors de la connexion à une instance RDS DB utilisant l'authentification IAM DB.

Question

Voici un résumé rapide de la question. Lisez la section de description complète pour les détails sous-jacents.

Description condensée :

Supposons que vous avez un utilisateur IAM déjà existant et que l'utilisateur est déjà en mesure d'accéder à d'autres services AWS, tels que S3, CloudFront, ECS, EC2....

Disons que nous devons fournir à l'utilisateur un accès en lecture seule sur le cluster RDS et configurer également l'authentification IAM DB.

Nous effectuons toutes les étapes mentionnées dans le guide officiel, dans NOTRE système local, et cela fonctionne parfaitement. Nous sommes en mesure de générer un jeton d'authentification correct pour l'utilisateur. db_user .

Cependant, c'est ici que cela devient intéressant lorsque l'utilisateur essaie de générer le jeton pour le programme db_user depuis sa machine locale l'utilisateur se verra refuser l'accès.

---

Description complète :

Mise en place :

Mon instance de cluster RDS utilise le moteur MySQL Aurora. Version du moteur : 5.6.10a

J'ai suivi le guide du centre de connaissances AWS sur Comment puis-je autoriser les utilisateurs à se connecter à Amazon RDS avec des informations d'identification IAM ?

Le guide ne le mentionne pas explicitement, mais lors de la génération du jeton d'authentification, AWS CLI utilise les informations d'identification IAM stockées localement, pour signer la demande.

J'aimerais le souligner dans l'extrait ci-dessous, admin est le nom du profil stocké par l'AWS CLI pour mon utilisateur IAM admin tandis que l'option db_user est l'utilisateur IAM (avec rds-db:connect privilèges).

TOKEN="$(aws --profile admin rds generate-db-auth-token -h.. .. .. -u db_user)

En utilisant l'extrait ci-dessus, je suis capable de m'authentifier avec le jeton généré et de me connecter au cluster.

Si --profile n'est pas mentionné, il lit le profil par défaut enregistré dans le fichier d'informations d'identification.

Question :

Au lieu d'utiliser --profile admin Je cherche à utiliser un profil IAM non administrateur déjà existant pour générer un jeton d'authentification.

Par exemple, supposons que l'utilisateur IAM nommé développeur avec des privilèges RDS en lecture seule et les informations d'identification stockées localement sous le profil rds_read_only

TOKEN="$(aws --profile rds_read_only rds generate-db-auth-token -h.. .. .. -u db_user)

Si j'utilise le jeton ci-dessus, j'obtiens l'erreur suivante :

ERROR 1045 (28000): Access denied for user 'db_user'@'ip' (using password: YES)

Après des heures de dépannage, j'ai pu conclure que ma rds_read_only est incapable de générer des jetons d'authentification valides, probablement parce que l'utilisateur IAM développeur est dépourvu de certaines politiques requises.

J'ai essayé de joindre toutes les politiques disponibles sous RDS y RDS Data API (individuellement ainsi qu'en combinaison) à l'utilisateur IAM développeur sans succès. Si je joins le AdministrativeAccess à l'utilisateur IAM développeur alors seulement il est capable de générer le jeton avec succès.

Question :

Quelles sont les politiques obligatoires requises pour que les utilisateurs IAM non administrateurs puissent générer un jeton d'authentification avec succès ?

Answer 1

J'ai vu votre question dans AWS Blog.

1. Vous devez créer une politique IAM pour définir l'accès à vos instances AWS RDS. Vérifiez ceci docs

   { "Version" : "2012-10-17", "Déclaration" : [ ] { "Effet" : "Autoriser", "Action" : [ [ ] ], "Resource" : [ "arn:aws:rds-db:us-east-2:1234567890:dbuser: / " ] [ ] ] }

2. Créez un utilisateur dans l'instance de la base de données RDS en suivant les instructions pour utiliser un plugin IAM. Vérifiez ceci docs

3. Créez le jeton en vérifiant ceci docs

4. J'ai trouvé ceci bon plugin qui construit un jar JDBC pour permettre l'authentification IAM.

Answer 2

Cela répond à la question spécifique de @Ronnie concernant la génération de jetons.

Ronnie, je suis de retour. J'ai utilisé la politique suivante dans mon compte AWS : Sandbox Je suis un utilisateur AWS Federated avec des priveleges AssumeRole donc Admin

Il faut être très prudent car, comme vous l'avez dit, l'article ne fait pas la distinction entre les deux :

AWS IAM USER utilisant un jeton généré pour accéder à la base de données. y

Utilisateur/rôle AWS IAM avec les bonnes politiques d'administration qui génère un jeton VALIDE

Je vais vous donner un exemple de la façon d'identifier les jetons générés correctement. Pour une raison quelconque, AWS génère une valeur mais ne vous dit pas s'il s'agit d'un jeton utile ou non.

Token sans accès spécial admin= NE FONCTIONNE PAS

sandboxdb.asdasdffw.ap-southeast-2.rds.amazonaws.com:3306/?Action=connect&DBUser=human_user&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIA5XZIHS3GYVMRPRZF%2F20200424%2Fap-southeast-2%2Frds-db%2Faws4_request&X-Amz-Date=20200424T035250Z&X-Amz-Expires=900&X-Amz-SignedHeaders=host&X-Amz-Signature=3efd467d548ea05a8bdf097c132b03661680908f723861e45323723c870ef646

Token avec Access= Ça marchera ! Regardez attentivement et il contient X-Amz-Security-Token= (en anglais)

sandboxdb.ras21th1z8.ap-southeast-2.rds.amazonaws.com:3306/?Action=connect&DBUser=human_user&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=ASIA5XZIHS3GSAQI6XHO%2F20200424%2Fap-southeast-2%2Frds-db%2Faws4_request&X-Amz-Date=20200424T040756Z&X-Amz-Expires=900&X-Amz-SignedHeaders=host&X-Amz-Security-Token=IQoJb3JpZ2luX2VjEEQaDmFwLXNvdXRoZWFzdC0yIkgwRgIhAOzVIondlMxYkJG5nWNeQlxS0M6B1pphgD1ewFwx2VfKAiEAkcp2jNHHmNMgwqUholnW545MwjzoEjS1uh4BHI4R4GAqvgMIbRABGgw5NDQ0NDAzMTc2NDUiDEvFkyEy833kd%2By4nyqbAybqK5dcP0nTlqZ19I2OVZxzwzz%2BUv9RVdVLMPHE5b%2FqXQGVG1CRtw90r9Lt4QkzTBeIVzdtIkXbpwFtqFh24Djb%2BiZHfvElj%2Fhz29ExzStU0fPYMewEB1u%2F2Osi72Fw6KbZ6TDy5EjuWcrrS08PZQ9CHc%2Fc8iDAIKs28vJ70KKcmow0SInVZGHGpD2JAgIL7jvnadVlcAW7lN2OAnxS72Kb4neqNuHcWzfPLfbXaOP1OaOs7vCR7zDlTTxX2aHoVflC69K9K67BqzdnDnnju%2F4XWQWU3r%2ByXylExwOsiG3y4Qq6wv002l%2BpQmF5%2BMXdTrFR5ewpfrcHf8TZLI5eq8HLA2gG1%2B255L%2Bqt%2BD80T%2FCzEdKSJPjppdYSq9FdeCMRSsqp5PpXP%2BDbQZwmhxiE2RmrbOKwNsFPJqUUnemQHXYLB8lily56nnswT2PYmQOGHqnZWRrv%2FTlGOAGlThuiR%2BLhQLBC08nBEGbBqK%2FjU4JwFMY4JfhgUHr8BA9CuGwAu0qIAFzG71M3HzCNX6o56k1gYJB%2F3%2FJaKlp7TCIxIn1BTrqASqywcfKrWhIaNX3t%2BV%2FZoYYO%2FtGVBZLyr3sSmByA%2Fwq538LiPHA0wDE3utOg%2FwNP%2BQGTcXhk1F%2BI0HOHztAQ2afnKW8r1oRbXxYAzb2j2b8MNEwrsaBju2gHFRgZHkM8YI%2FP5cvYr%2F8FQXWcE9eqjdme0hOo3rPETzxZfRwNQTHEntBbVVD1ec0d7DblfSEDZhLk%2By1%2BFMAYf7NeBIfU6GNsAN2hTdSkPPuto2fQKzRybRAwxQz5P3cO5CClUNIxu4J3bM1MUUTux%2BtMjqRvjGxDhB4yLIJmIPOOYLDSOXl3aWO2y4v89wu5A%3D%3D&X-Amz-Signature=1c6fcc472bb2af09055117075ca21d4a5f715910443115116c9230905721e79d

Politique AWS IAM pour l'utilisateur de la base de données pour se connecter à l'instance de base de données AWS RDS

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "rds-db:connect",
            "Resource": "*"
        }
    ]
}

Pour éviter d'avoir à manipuler les configurations locales, j'ai utilisé le processus de test suivant :

1. Génération de jetons à partir d'une instance AWS EC2 fonctionnant dans le même VPC que la BD. La génération est réussie
2. Génération de jetons à partir de la machine locale en utilisant un conteneur Docker avec CLI D'AWS La génération de jetons est réussie.

Bien sûr mon utilisateur a été créé dans la base de données MySQL avec la commande suivante

mysql -h $HOSTNAME -u$ADMIN_USER -p$ADMIN_PASS <<EOF
CREATE USER db_human_user IDENTIFIED WITH AWSAuthenticationPlugin AS 'RDS';
GRANT SELECT ON $SPECIFIC_GIVEN_DB.* TO 'db_human_user';
EOF