Comment forcer https sur un haricot élastique?

Cette réponse suppose que vous avez déjà activé https dans le groupe de sécurité de l’équilibreur de charge, ajouté le certificate SSL à l’équilibreur de charge, ajouté 443 aux ports transférés par l’équilibreur de charge et indiqué service DNS équivalent).

REMARQUE: Cette réponse concerne les environnements Elastic Beanstalk qui utilisent Apache. Cela peut également ne pas fonctionner pour un déploiement basé sur docker.

Tout ce que vous avez à faire est d’append ce qui suit à l’un de vos fichiers .config dans le répertoire .ebextensions de votre projet :

 files: "/etc/httpd/conf.d/ssl_rewrite.conf": mode: "000644" owner: root group: root content: | RewriteEngine On  RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]  

Explication

Ceci est modérément simple en dehors de Elastic Beanstalk. On ajoute généralement une règle de réécriture Apache comme suit:

 RewriteCond %{HTTPS} off RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} 

Ou, si derrière un équilibreur de charge, comme dans ce cas:

 RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L] 

Cependant, ces configurations ne fonctionnent que dans un bloc . Changer le RewriteCond en un bloc permet de fonctionner correctement en dehors d’un bloc , ce qui nous permet de le placer dans un fichier de configuration Apache autonome. Notez que l’installation standard d’Apache sur CentOS (y compris la configuration sur ElasticBeanstalk) inclut tous les fichiers correspondant à /etc/httpd/conf.d/*.conf , qui correspondent au chemin de fichier où nous stockons ce fichier.

La partie -n '%{HTTP:X-Forwarded-Proto}' de la condition l’empêche de se redirect si vous n’êtes pas derrière un équilibreur de charge, ce qui vous permet d’avoir une configuration partagée entre un environnement de production avec un équilibreur de charge et https, et un environnement de transfert qui est à instance unique et n’a pas https. Cela n’est pas nécessaire si vous utilisez des équilibreurs de charge et des https sur tous vos environnements, mais cela ne fait pas de mal de l’avoir.

Les mauvaises solutions que j’ai vues

J’ai vu beaucoup de mauvaises solutions à ce problème, et cela vaut la peine de les parcourir pour comprendre pourquoi cette solution est nécessaire.

1. Utiliser Cloudfront: Certaines personnes suggèrent d’utiliser une configuration Cloudfront non mise en cache devant Elastic Beanstalk pour effectuer la redirection HTTP vers HTTPS. Cela ajoute un tout nouveau service (ajoutant ainsi de la complexité) qui n’est pas exactement approprié (Cloudfront est un CDN, ce n’est pas le bon outil pour forcer le HTTPS sur du contenu insortingnsèquement dynamic). La configuration d’Apache est la solution normale à ce problème et Elastic Beanstalk utilise Apache.

2. SSH dans le serveur et …: Ceci est complètement antithétique au point d’Elastic Beanstalk et a tellement de problèmes. Toute nouvelle instance créée par Autoscaling n’aura pas la configuration modifiée. Tous les environnements clonés n’auront pas la configuration. Un nombre quelconque de modifications raisonnables de l’environnement effacera la configuration. C’est une si mauvaise idée.

3. Remplacez la configuration d’Apache par un nouveau fichier: Cela entre dans le bon domaine de solution mais vous laisse un cauchemar de maintenance si Elastic Beanstalk modifie certains aspects de la configuration du serveur (ce qu’ils peuvent très bien faire). Voir aussi les problèmes dans le prochain article.

4. Éditez dynamicment le fichier de configuration Apache pour append quelques lignes: Ceci est une idée décente. Le problème est que cela ne fonctionnera pas si Elastic Beanstalk modifie jamais le nom de son fichier de configuration Apache par défaut, et que ce fichier peut être écrasé lorsque vous vous y attendez le moins: https://forums.aws.amazon.com/thread .jspa? threadID = 163369

EDIT: Bien que j’adore cette réponse, elle est maintenant très ancienne . AWS a mis au sharepoint nouveaux services (tels que Certificate Manager ) qui rendent une partie de cette réponse obsolète. De plus, l’utilisation du dossier .ebextensions avec Apache est un moyen plus propre de gérer cette redirection, comme expliqué ci-dessus.

Si vous hébergez votre site Web sur S3, certaines parties de cette réponse pourraient vous être utiles.

Cela a fonctionné pour moi:

1. Téléchargez le certificate sur AWS à l’aide de la commande aws console. La structure de commande est la suivante:

    aws iam upload-server-certificatee --server-certificatee-name CERTIFICATE_NAME --certificatee-body "file://PATH_TO_CERTIFICATE.crt" --private-key "file://YOUR_PRIVATE_KEY.pem" --certificatee-chain "file://YOUR_CERTIFICATE_CHAIN.ca-bundle" --path /cloudfront/ 

2. Dans votre application Elastic Beanstalk, accédez à Configuration -> Niveau réseau -> Équilibrage de la charge et cliquez sur l’ icône représentant un engrenage .

3. Sélectionnez Port d’écoute sécurisé en tant que 443 . Sélectionnez Protocole comme HTTPS . Sélectionnez le CERTIFICATE_NAME de l’ étape 2 pour l’ID de certificate SSL . Enregistrez la configuration.

4. Accédez à votre console . Cliquez sur Instances EC2 . Cliquez sur Load Balancers . Cliquez sur les équilibreurs de charge. Cliquez sur Instances et faites défiler la liste pour voir les instances EC2 affectées à cet équilibreur de charge. Si l’instance EC2 porte le même nom que votre URL d’application (ou quelque chose de proche), notez le nom DNS de l’équilibreur de charge. Il devrait être au format awseb-e-...

5. Retournez dans votre console . Cliquez sur CloudFront . Cliquez sur Créer une dissortingbution . Sélectionnez une dissortingbution Web .

6. Configurez la dissortingbution. Définissez votre nom de domaine d’origine sur le nom DNS de l’équilibreur de charge que vous avez trouvé à l’ étape 5 . Définissez la stratégie de protocole du visualiseur pour redirect HTTP vers HTTPS . Définissez les chaînes de requête de transfert sur Oui . Définissez les noms de domaine alternatifs (CNAME) sur les URL que vous souhaitez utiliser pour votre application. Définissez le certificate SSL sur CERTIFICATE_NAME vous avez téléchargé à l’ étape 2 . Créez votre dissortingbution.

7. Cliquez sur votre nom de dissortingbution dans CloudFront. Cliquez sur Origines , sélectionnez votre origine et cliquez sur Modifier . Assurez-vous que votre stratégie de protocole d’origine est Match Viewer . Retourner. Cliquez sur Comportements , sélectionnez votre origine et cliquez sur Modifier . Modifier les en- têtes de transfert en liste blanche et append un hôte . Sauvegarder.

Note: J’ai aussi écrit un guide plus long .

Le plus voté ne fonctionne pas pour moi .. la directive ne fonctionne qu’avec Apache 2.4+, mais ElasticBeanstalk a la version 2.2.x.

Donc, en suivant les mêmes conseils que ci-dessus. Créez un fichier appelé .ebextensions / https_rewrite.config avec le contenu suivant

 files: "/etc/httpd/conf.d/ssl_rewrite.conf": mode: "000644" owner: root group: root content: | LoadModule rewrite_module modules/mod_rewrite.so RewriteEngine On # This will enable the Rewrite capabilities RewriteCond %{HTTPS} !=on # This checks to make sure the connection is not already HTTPS RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L] 

Cela semble fonctionner pour moi.

Pour savoir comment créer ce fichier dans votre fichier WAR, consultez cette réponse.

Edit: La solution Zags est plus générale et correcte. Je le recommande sur le mien (qui est spécifique à un env Python)

Voici une solution propre et rapide que j’ai trouvée qui évite le piratage de wsgi.conf ou l’utilisation de CloudFront

Dans votre .ebextensions / some_file.config:

 # Redirect HTTP to HTTPS "/etc/httpd/conf.d/https_redirect.conf": mode: "000644" owner: root group: root content: |  RewriteEngine on RewriteCond %{HTTP:X-Forwarded-Proto} ^http$ RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]  

J’ai l’impression que c’est trop facile, mais semble fonctionner correctement.

Notez également que je redirige explicitement HTTP au lieu de “pas HTTPS”.

Cela fonctionne pour moi avec la commande suivante:

 RewriteCond %{HTTP:X-Forwarded-Port} !=443 

et sans la vérification https:

 RewriteCond %{HTTP:X-Forwarded-Proto} !https 

On dirait que ELB change la valeur de X-Forwarded-Proto en http (même sur le protocole TCP).

Aucune des réponses ci-dessus n’a fonctionné pour moi mais certaines m’ont aidé à trouver la réponse qui a fonctionné pour moi. J’ai également trouvé l’URL ci-dessous qui a aidé http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/java-tomcat -platform.html

J’ai créé la structure de fichier mentionnée ci-dessus pour modifier 2 fichiers httpd.conf 00_application.conf

Copiez le fichier httpd.conf complet de votre instance et placez-le dans votre code sous .ebextention sous la structure de dossiers mentionnée dans le lien ci-dessus. Ajoutez simplement la ligne ci-dessous à ce fichier dans votre projet.

 LoadModule rewrite_module modules/mod_rewrite.so 

Faites la même chose pour 00_application.conf, copiez-la à partir de votre instance et placez-la dans votre code sous .ebextention sous httpd / conf.d / elasticbeanstalk / 00_application.conf. Maintenant, éditez ce fichier et ajoutez ce qui suit entre VirtualHost

 RewriteEngine on RewriteCond %{HTTP:X-Forwarded-Proto} =http RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] 

Maintenant, déployez votre code. Il devrait fonctionner.

J’essaie de redirect une tige de haricot élastique avec loadbalancer en 2018. Aucune des réponses ci-dessus ne fonctionne dans mon environnement. Plusieurs problèmes que j’ai rencontrés:

1. J’essayais la réponse la plus votée, mais mon tomcat est la version 2.7. Il ne supporte pas.

2. J’utilisais container_commands et copiais le paramètre 00_applications. AWS l’ignore simplement.

Donc finalement, je l’ai fait en lisant ceci: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/java-tomcat-proxy.html

Voici ce que je fais:

J’ai recréé la structure du dossier:

 .ebextensions - httpd -conf.d -ssl.conf 

Et puis c’est le contenu de ssl.conf

  RewriteEngine on RewriteCond %{HTTP:X-Forwarded-Proto} =http RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]  Order Allow,Deny Allow from all  ProxyPass / http://localhost:8080/ retry=0 ProxyPassReverse / http://localhost:8080/ ProxyPreserveHost on ErrorLog /var/log/httpd/elasticbeanstalk-error_log  

J’espère que cela aidera.

Sur élastique beanstalk, vous pouvez simplement append votre on-configuration afin qu’AWS écrase son, cela vous permettra d’écraser la configuration du serveur Web et de soumettre votre propre configuration.

Ajoutez simplement le fichier suivant sous le chemin: .ebextensions \ httpd \ conf.d

Contenu du fichier:

  LoadModule rewrite_module modules/mod_rewrite.so RewriteEngine On RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteCond %{HTTP_USER_AGENT} !ELB-HealthChecker RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}  Order deny,allow Allow from all  ProxyPass / http://localhost:8080/ retry=0 ProxyPassReverse / http://localhost:8080/ ProxyPreserveHost on ErrorLog /var/log/httpd/elasticbeanstalk-error_log  

Le fichier .ebextensions est le dossier de configuration standard dans AWS et le rest indique simplement le fichier et le dossier que vous souhaitez écraser. Si le fichier ou le dossier n’existe pas, créez-les simplement.

J’ai eu du mal à comprendre cela. Après avoir trouvé une solution, j’ai écrit une explication détaillée de ma solution pour aider quelqu’un d’autre. Ceci est spécifique à Tomcat 8, Apache2 et à l’application Spring Boot. Il existe des exemples très utiles d’ ebextension dans le github d’AWS Labs .

Résumé de ce qui a fonctionné pour moi:

1. Créez un fichier dans /src/main/webapp/.ebextensions/httpd/conf.d/elasticbeanstalk.conf
2. Ajouter des conds / règles de réécriture en prenant soin d’inclure “LoadModule rewrite_module modules / mod_rewrite.so”
3. Déployer sur AWS EBS

Voici un exemple d’application Spring Boot .

J’ai les configurations suivantes pour beanstalk élastique (Amazon Linux 2016.09 v2.3.1 64 bits exécutant Tomcat 8 Java 8). J’ai créé un répertoire .ebextensions et ajouté un fichier .config YAML avec les conditions de réécriture

La solution Zagas décrite ci-dessus (qui est très complexe) ne fonctionne pas pour moi.

1. Parce que “Si” condition est inconnue
2. À cause d’Apache 2.2, mod_rewrite.so n’est pas inclus dans mon fichier httpd.conf

Cette solution a plus de sens pour moi, mais cela ne fonctionne pas. Rien ne se passe, et je ne peux pas voir le fichier “ssl_rewrite.conf” sous le répertoire “conf.d”.

La troisième solution essayée consistait à append les fichiers “run.config” et “ssl_rewrite.conf” sous le répertoire “.ebextendsion”.

run_config contient

 container_commands: copy-config: command: "cp .ebextensions/ssl_rewrite.conf /etc/httpd/conf.d" 

ssl_rewrite.conf contient

 LoadModule rewrite_module modules/mod_rewrite.so RewriteEngine On RewriteCond %{HTTP:X-Forwarded-Proto} =http RewriteRule . https://%{HTTP:Host}%{REQUEST_URI} [L,R=permanent] 

ssl_rewrite.conf est créé sous direcotry “conf.d” mais la redirection de http vers https ne fonctionne pas.

La seule solution efficace pour moi était d’append les lignes suivantes dans “/etc/httpd/conf.d/elasticbeanstalk/00_application.conf”

  ...... RewriteEngine on RewriteCond %{HTTP:X-Forwarded-Proto} =http RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] ......  

mais ceci est une solution temporaire et si une machine est remplacée, ma redirection https a disparu.

Pourquoi ne placez-vous pas simplement un fichier .htaccess dans le dossier racine? De cette façon, vous pouvez simplement tester et déboguer. Et si vous l’incluez dans le fichier .zip, il sera automatiquement déployé sur toutes les instances.

Utilisez simplement .htaccess :

 RewriteEngine on RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L] 

Veuillez noter que la réponse la plus votée est un peu ancienne maintenant. La réponse de A Paul est en fait la bonne réponse. Le lien fourni dans sa réponse est fourni par AWS (il est donc recommandé de remplacer votre configuration Apache pour effectuer la redirection de HTTP vers HTTPS lors de l’exécution de votre application sur Elastic Beanstalk).

Il y a une chose très importante à noter. Si vous déployez plus d’une application Web, l’ajout du dossier .ebextensions dans l’une de vos applications Web ne fonctionnera pas. Vous remarquerez que des configurations non spécifiées sont en cours d’écriture ou de création. Si vous déployez plusieurs applications Web Apps sur un environnement Elastic Beanstalk, vous devrez alors lire cet article AWS Java Tomcat Déployer plusieurs fichiers WAR sur Elastic Beanstalk

En général, vous devez avoir la structure suivante avant de lancer la commande eb pour déployer les fichiers WAR:

 MyApplication.zip ├── .ebextensions ├── foo.war ├── bar.war └── ROOT.war 

Si le dossier .ebextentions existe dans chaque fichier WAR, vous remarquerez qu’il est complètement ignoré et qu’aucune modification de configuration ne sera effectuée.

J’espère que ceci aide quelqu’un d’autre.

Nous l’avons résolu sur notre backend en gérant correctement X-Forwarded-Proto .

Ceci est notre configuration de Grails mais cela vous aidera dans l’idée:

  grails.plugin.springsecurity.secureChannel.useHeaderCheckChannelSecurity = true grails.plugin.springsecurity.portMapper.httpPort = 80 grails.plugin.springsecurity.portMapper.httpsPort = 443 grails.plugin.springsecurity.secureChannel.secureHeaderName = 'X-Forwarded-Proto' grails.plugin.springsecurity.secureChannel.secureHeaderValue = 'http' grails.plugin.springsecurity.secureChannel.insecureHeaderName = 'X-Forwarded-Proto' grails.plugin.springsecurity.secureChannel.insecureHeaderValue = 'https' grails.plugin.springsecurity.secureChannel.definition = [ [pattern: '/**', access: 'REQUIRES_SECURE_CHANNEL'] ] 

Pour étendre encore deux réponses à cette question, https://stackoverflow.com/a/43026082/8775205 , https://stackoverflow.com/a/42035023/8775205 . Pour les utilisateurs de boot de spring qui déploient leurs services sur AWS avec ELB et qui ont besoin d’un guide étape par étape, vous pouvez append un fichier ****. Conf sous src / main / webapp / .ebextensions / httpd / conf.d / dans votre projet .

 src --main ----java ----resources ----webapps ------.ebextensions --------httpd ----------confd ------------****.conf 

****. conf ressemble à ceci Remarqué que j’ai mon site de test avec une seule instance, donc j’ajoute une condition pour l’exclure.

  LoadModule rewrite_module modules/mod_rewrite.so RewriteEngine On RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteCond %{HTTP_USER_AGENT} !ELB-HealthChecker RewriteCond %{HTTP_HOST} !testexample.com #excludes test site RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}  Order deny,allow Allow from all  ProxyPass / http://localhost:8080/ retry=0 ProxyPassReverse / http://localhost:8080/ ProxyPreserveHost on ErrorLog /var/log/httpd/elasticbeanstalk-error_log  

Après cela, n’oubliez pas d’append une “ressource” sous maven-war-plugin dans votre pom.xml afin de prendre la configuration ci-dessus.

  org.apache.maven.plugins maven-war-plugin       src/main/webapps/.ebextensions .ebextensions true    2.1.1  

Enfin, validez et poussez votre code, attendez le codebuild AWS et la ligne de code pour récupérer votre code dans votre référentiel et déployez-le dans un environnement beanstalk, ou compressez simplement votre projet dans un fichier war et téléchargez-le sur votre environnement AWS beanstalk.

AWS n’accepte pas les caractères de soulignement (_) dans les en-têtes, alors que nous pouvons utiliser (-), Donc Supprimer les traits de soulignement des variables d’en-tête, par exemple: – header_var_val = “some value” le remplace par headervarval = “some value” . Ça marche pour moi.

Si vous utilisez un environnement Load Balanced, vous pouvez suivre les instructions de Configuration de HTTPS pour votre environnement AWS Elastic Beanstalk et, à la fin, désactiver le port HTTP.

Notez que le niveau d’utilisation gratuite d’AWS inclut actuellement le même nombre d’heures pour un ELB (Elastic Load Balancing) que pour une instance Micro EC2.

c’est une solution facile

1. ssh dans votre instance EC2
2. copier le contenu de /etc/httpd/conf.d/wsgi.conf dans un fichier local appelé wsgi.conf qui sera placé dans le dossier de base de votre application

3. Modifiez la version locale de wsgi.conf et ajoutez les règles de redirection suivantes dans les balises

    RewriteEngine On RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteRule !/status https://%{SERVER_NAME}%{REQUEST_URI} [L,R=301] 

4. Remplacez le “/ status” par la page que vous utilisez comme page de vérification de l’ intégrité.

5. Enregistrez le fichier

6. Modifiez votre fichier .conf dans votre fichier. Répertoire ebextensions pour append une commande de conteneur pour copier cette version de wsgi.conf sur la version d’Amazon

    container_commands: 01_syncdb: command: "django-admin.py syncdb --noinput" leader_only: true 02_collectstatic: command: "django-admin.py collectstatic --noinput" 03_wsgireplace: command: 'cp wsgi.conf ../wsgi.conf' ... 

7. Déployez le code.

8. La version déployée de wsg.conf dans /etc/httd/conf.d/wsgi.conf inclura désormais les règles de redirection nécessaires.

Cela devrait fonctionner et le fichier sera correctement mis à jour pour chaque déploiement. La seule chose à surveiller est que si Amazon modifie son contenu de base de fichier wsgi.conf à l’avenir, votre copie risque de ne plus fonctionner.

Autor rickchristianson