Support IMDSv2

Installation
1

Je vous écris pour me renseigner sur la prise en charge d’IMDSv2 via les profils d’instance dans Discourse. Nous sommes en train de migrer notre service pour utiliser IMDSv2, car IMDSv1 n’est pas une option sécurisée.

Nous aimerions savoir si Discourse prend actuellement en charge IMDSv2 via les profils d’instance et, si ce n’est pas le cas, quels sont les plans pour le prendre en charge dans un avenir proche. De plus, existe-t-il des solutions de contournement ou des correctifs disponibles qui nous permettraient d’utiliser IMDSv2 avec Discourse ?

Il est important pour nous de nous assurer que nos exigences de sécurité sont satisfaites, et nous pensons que l’utilisation d’identifiants temporaires via IMDSv2 en est un aspect essentiel.

Le comportement souhaité pour accéder aux identifiants de sécurité fournis via le profil d’instance est :

  • Une application sur l’instance récupère les identifiants de sécurité fournis par le rôle à partir de l’élément de métadonnées de l’instance iam/security-credentials/ role-name.
  • L’application se voit accorder les autorisations pour les actions et les ressources que nous avons définies pour le rôle via les identifiants de sécurité associés au rôle. Ces identifiants de sécurité sont temporaires et sont automatiquement mis à jour. Nous rendons de nouveaux identifiants disponibles au moins cinq minutes avant l’expiration des anciens identifiants.

Nous avons noté qu’il existe des différences entre les appels IMDSv1 et IMDSv2.

Appel IMDSv1 :

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/s3access

Alors que l’appel IMDSv2 nécessite l’utilisation d’un jeton de métadonnées, et peut être effectué en utilisant les commandes suivantes :

TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \\\\\\\\\\\\\\\\
&& curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/iam/security-credentials/s3access

Nous apprécierions toute information que vous pourrez nous fournir sur la manière dont nous pouvons utiliser IMDSv2 avec Discourse, ou s’il existe des solutions de contournement ou des correctifs disponibles.

Référence :

3

Je ne connais aucun moyen par lequel Discourse lui-même utilise IMDS. Avez-vous installé Discourse sur AWS d’une manière ou d’une autre ? Utilisez-vous déjà IMDSv1 avec Discourse ?

Quel est votre cas d’utilisation ?

5

J’ai trouvé un code associé.

6

Ceci est dans la spécification de test.

Discourse utilise une version du SDK AWS (3.130.2) supérieure au minimum requis pour prendre en charge IMDSv2 et d’après ce que je peux voir en examinant la métrique MetadataNoToken dans nos déploiements AWS, nous n’avons aucun appel à IMDSv1.

D’après ce que je peux dire, nous utilisons déjà IMDSv2 partout.

3 « J'aime »
7

Nous avons commencé à utiliser Discourse sur une instance AWS EC2 il y a un an. Et cette semaine, nous avons mis à jour notre instance pour n’utiliser que IMDSv2, cela a cassé nos téléchargements AWS S3 avec le message d’erreur « unable to sign request without credentials set ». Nous utilisons également le paramètre « s3 use iam profile ».

Le service IMDS local est utilisé par Discourse pour obtenir les identifiants nécessaires à d’autres appels d’API de services liés à AWS. Ceci est fait en utilisant Ruby aws-sdk-s3

8

Nous constatons également ce problème de sauvegarde après avoir désactivé IMDSv1 pour des raisons de sécurité.

Nous pouvons voir l’utilisation d’IMDSv1 (dans 3.3.0.beta1-dev) via la métrique MetadataNoToken, nous nous demandons donc à quelle version de Discourse est passée à l’utilisation de v2 partout ?

9

Nous avons également été affectés par cela aujourd’hui une fois que nous avons configuré notre instance AWS pour utiliser uniquement IMDSv2 : nos utilisateurs ne pouvaient plus télécharger d’images sur S3.

Probablement pertinent ici : nous utilisons également l’option s3 use iam profile.

Pour l’instant, nous l’avons basculée sur « Facultatif », ce qui signifie essentiellement que IMDSv1 est toujours activé, ce qui n’est pas idéal en termes de sécurité, mais cela a permis aux téléchargements de fonctionner à nouveau.

1 « J'aime »
10

Quelqu’un a-t-il une solution/un contournement pour faire fonctionner Discourse avec IMDSv2 ?

11

Nous apportons des modifications pour permettre/s’attendre à ce que plus de configuration soit possible via le fichier .aws/config, ce qui pourrait coïncider avec cela et le rendre possible.

15

@supermathie la chose la plus étrange que je n’arrive pas à comprendre, c’est que j’ai personnellement configuré 2 instances de Discourse (dev/prod) qui sont configurées de manière identique (téléchargements S3 pour les fichiers et sauvegarde à l’aide du profil IAM) et mises à jour vers une version identique (9436f5e3d4) et lorsque j’ai désactivé IMDSv1… en dev, tout a continué à fonctionner comme prévu, tandis qu’en prod, cela ne fonctionne pas et continue de renvoyer quelque chose comme « impossible de signer la requête sans identifiants définis »… assez déroutant.

Si vous avez une idée de test/vérification que je pourrais faire, faites-le moi savoir.

16

@ducks a identifié que les délais d’attente dans le SDK pour l’acquisition des informations d’identification IMDS sont très agressifs (1 seconde, sans nouvelles tentatives), il est donc possible que ce soit ce délai d’attente qui soit atteint.

Mais ce n’est qu’une supposition.

Si vous vous connectez à la production via la console, pouvez-vous le faire interactivement, par exemple :

discourse(prod)> c = Aws::S3::Client.new(region: ENV['DISCOURSE_S3_REGION'])
=> #<Aws::S3::Client>

discourse(prod)> c.list_objects_v2(bucket: ENV['DISCOURSE_S3_BUCKET']).contents.count
=> 1000
1 « J'aime »
17

J’ai compris ce qui n’allait pas et je dois m’en vouloir, mais le problème était assez subtil.
Le problème venait de « HttpPutResponseHopLimit » réglé sur 1, ce qui ne permettait pas d’appeler IMDSv2 depuis l’intérieur du conteneur.

En exécutant cette commande, j’ai obtenu cette réponse :

> aws ec2 describe-instances --instance-ids i-00000000000000000 --query “Reservations[0].Instances[0].MetadataOptions”`
{
"State": "applied",
"HttpTokens": "optional",
"HttpPutResponseHopLimit": 1,
"HttpEndpoint": "enabled",
"HttpProtocolIpv6": "disabled",
"InstanceMetadataTags": "disabled"
}

En ajustant le paramètre, la sortie correcte est

> aws ec2 describe-instances --instance-ids i-00000000000000000 --query “Reservations[0].Instances[0].MetadataOptions”`
{
"State": "applied",
"HttpTokens": "required",
"HttpPutResponseHopLimit": 2,
"HttpEndpoint": "enabled",
"HttpProtocolIpv6": "disabled",
"InstanceMetadataTags": "disabled"
}

… et finalement le mystère est résolu :sweat_smile:

Merci à tous pour votre aide

1 « J'aime »
18

C’est une excellente nouvelle à savoir !

Et espérons que cela s’applique aux autres également.

Mais je me demande pourquoi ce n’est pas un problème pour nous. Nous avons ceci réglé sur 1 et pourtant cela fonctionne ?

discourse(prod) > ENV['AWS_EC2_METADATA_V1_DISABLED'] = 'true'
=> "true"
discourse(prod) > c = Aws::S3::Client.new(region: ENV['DISCOURSE_S3_REGION'])
=> #<Aws::S3::Client:0x00007f86d0000000>
discourse(prod) > c.config.credentials.disable_imds_v1
=> true
discourse(prod) > c.list_objects_v2(bucket: ENV['DISCOURSE_S3_BUCKET']).contents.count
=> 1000

et cette instance a les métadonnées suivantes selon la même commande de requête :

{
    "State": "applied",
    "HttpTokens": "optional",
    "HttpPutResponseHopLimit": 1,
    "HttpEndpoint": "enabled",
    "HttpProtocolIpv6": "disabled",
    "InstanceMetadataTags": "disabled"
}

Nous exécutons Discourse dans un conteneur Docker sur EC2, comme les autres, alors… quelle est la différence ?

19

Ce sujet a été automatiquement fermé après 21 heures. Les nouvelles réponses ne sont plus autorisées.