Comment forcer les https sur les tiges de haricot élastiques?

cette réponse suppose que vous avez déjà activé https dans le load balancer security group, ajouté le certificat SSL au load balancer, ajouté 443 aux ports transmis par le load balancer, et pointé votre nom de domaine vers L'environnement Beanstalk élastique avec la Route 53 (ou service DNS équivalent).

NOTE: Cette réponse s'applique aux environnements en haricot magique qui utilisent Apache. Il se peut également que cela ne fonctionne pas pour un déploiement basé sur un docker.

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

files:
    "/etc/httpd/conf.d/ssl_rewrite.conf":
        mode: "000644"
        owner: root
        group: root
        content: |
            RewriteEngine On
            <If "-n '%{HTTP:X-Forwarded-Proto}' && %{HTTP:X-Forwarded-Proto} != 'https'">
            RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
            </If>

explication

c'est modérément droit en dehors de la tige élastique. On ajoute habituellement une règle de réécriture Apache comme celle-ci:

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

Ou, si derrière un répartiteur de charge, comme nous sommes dans ce cas:

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

cependant, ces configurations ne fonctionnent qu'à l'intérieur d'un bloc <VirtualHost> . Le fait de changer le bloc RewriteCond en bloc <If> lui permet de fonctionner correctement en dehors d'un bloc <VirtualHost> , ce qui nous permet de le mettre dans un fichier de configuration Apache autonome. Notez que la configuration standard D'Apache sur CentOS (y compris la configuration sur ElasticBeanstalk) inclut tous les fichiers correspondant à /etc/httpd/conf.d/*.conf , ce qui correspond au chemin du fichier où nous stockons ce fichier.

la partie -n '%{HTTP:X-Forwarded-Proto}' de la condition l'empêche de rediriger si vous n'êtes pas derrière un équilibreur de charge, vous permettant d'avoir une configuration partagée entre un environnement de production avec un équilibreur de charge et https, et un environnement de staging qui est une seule instance et n'a pas https. Ce n'est pas nécessaire si vous utilisez des équilibres de charge et des https sur tous vos environnements, mais cela ne fait pas de mal de l'avoir.

de Mauvaises solutions, j'ai vu

j'ai vu beaucoup de les mauvaises solutions à ce problème, et il vaut la peine d'aller à travers eux pour comprendre pourquoi cette solution est nécessaire.

1. utilisez Cloudfront: certaines personnes suggèrent d'utiliser la configuration Cloudfront non mise en cache devant Elastic Beanstalk pour faire la redirection HTTP vers HTTPS. Cela ajoute un tout nouveau service (ce qui ajoute de la complexité) qui n'est pas tout à fait approprié (Cloudfront est un CDN; ce n'est pas le bon outil pour forcer HTTPS sur inherant contenu dynamique). Apache config est la solution normale à ce problème et Elastic Beanstalk utilise Apache, donc c'est la façon dont nous devrions aller.

2. SSH sur le serveur...: c'est complètement antithétique au point de diaphragme élastique et a tellement de problèmes. Toutes les nouvelles instances créées par autoscaling n'auront pas la configuration modifiée. Tous les environnements clonés n'auront pas la configuration. N'importe quel nombre d'un un ensemble raisonnable de modifications de l'environnement effacera la configuration. C'est juste une mauvaise idée.

3. "Ecrivez la config Apache avec un nouveau fichier: C'est entrer dans le bon domaine de solution mais vous laisse avec un cauchemar de maintenance si Elastic Beanstalk change les aspects de la configuration du serveur (ce qu'ils peuvent très bien faire). Voir aussi les problèmes au point suivant.

4. éditez dynamiquement le fichier de configuration Apache pour y ajouter quelques lignes: c'est une bonne idée. Le problème est que cela ne fonctionnera pas si Elastic Beanstalk change le nom de son fichier de configuration Apache par défaut, et que ce fichier peut être écrasé quand vous vous attendez le moins: https://forums.aws.amazon.com/thread.jspa?threadID=163369

EDIT: Pendant que j'aime cette réponse, c'est maintenant très vieux . AWS a proposé de nouveaux services (comme 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 peut encore être utile pour vous.

cela a fonctionné pour moi:

1. Télécharger le certificat à AWS à l'aide de la aws de la console de commande. La structure de commande est:

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

2. dans votre application en haricot magique, passez à Configuration - > niveau réseau - > charge Équilibrage et cliquez sur l'icône de l'engrenage .

3. , Sélectionnez Sécuriser le port d'écoute comme 443 . Sélectionnez protocole comme HTTPS . Sélectionnez le CERTIFICATE_NAME de étape 2 pour numéro de certificat SSL . Enregistrer la configuration.

4. Go à votre Console . Cliquez sur EC2 Instances . Cliquez Sur Load Balancers . Cliquez sur les équilibreurs de charge. Cliquez sur Instances et faites défiler vers le bas pour voir les instances EC2 affectées à cet équilibreur de charge. Si L'instance EC2 a le même nom que l'URL de votre Application (ou quelque chose de proche), prenez note du nom DNS pour l'équilibreur de charge. Il doit être dans le format awseb-e-...

5. retournez à votre Console . Cliquez Sur CloudFront . Cliquez Sur Créer Une Distribution . Sélectionnez une distribution Web .

6. mettre en place la distribution. Réglez votre nom de domaine origine sur le nom DNS load balancer que vous avez trouvé dans étape 5 . Placer le Visionneuse de Protocole de la Politique à Redirection HTTP vers HTTPS . Set en Avant les Chaînes de Requête à Oui . Définissez Alternate Domain Names (CNAMEs) à L'URL(s) que vous souhaitez utiliser pour votre application. Mettez certificat SSL sur le CERTIFICATE_NAME que vous avez téléchargé dans étape 2 . Créez votre distribution.

7. Cliquez sur votre nom de distribution dans CloudFront. Cliquez sur Origines , sélectionnez votre origine, et cliquez sur Modifier . Assurez-vous que votre politique sur le protocole D'origine est Match Viewer . Revenir en arrière. Cliquez sur Comportements , sélectionnez votre origine, et cliquez sur Modifier . Remplacer en-têtes avant par liste blanche et ajouter hôte . Enregistrer.

Note: j'ai aussi écrit un guide plus long .

le plus rejeté ne marche pas pour moi.. la directive < If> ne fonctionne qu'avec Apache 2.4+, mais ElasticBeanstalk a la version 2.2.x.

donc, suivant le même conseil 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}/ [R,L]

Cela semble fonctionner pour moi.

sur la façon de construire ce fichier dans votre fichier de guerre, voir cette réponse

Edit: Zags solution est plus général et de les corriger. Je le recommande plus le mien (qui est spécifique à un python env)

Voici une solution propre et rapide que j'ai trouvé qui évite de pirater wsgi.conf ou à l'aide 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: |
      <Directory /opt/python/current/app/>
      RewriteEngine on
      RewriteCond %{HTTP:X-Forwarded-Proto} ^http$
      RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
      </Directory>

j'ai l'impression que c'est trop facile, mais semble fonctionner correctement.

notez aussi que je suis redirection explicite de HTTP au lieu de"not HTTPS".

c'est le travail pour moi avec la commande suivante:

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

et sans le contrôle https:

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

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

Aucune des réponses ci-dessus a fonctionné pour moi, mais certains m'ont aidé à trouver la réponse qui a fonctionné pour moi J'ai aussi 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 dans l'url ci-dessus pour changer 2 fichiers httpd.conf 00_application.conf

copiez tout le httpd.conf de votre instance et le mettre dans votre code sous .ebextension sous la structure de dossier mentionnée dans le lien ci-dessus. Puis il suffit d'ajouter 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-le à partir de votre instance et placez-le dans votre base de données .ebextension under 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]

déployez maintenant votre code Il devrait fonctionner.

j'essaie de rediriger un haricot élastique avec loadbalancer en 2018. Aucune des réponses ci-dessus fonctionne dans mon environnement. J'ai encouragé plusieurs questions:

1. j'essayais la réponse la plus votée, mais mon tomcat est la version 2.7. Il ne prend pas en charge .

2. j'utilisais container_commands et copiais le paramètre 00_applications. AWS simplement les ignorer.

donc finalement j'ai réussi à le faire marcher 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 voici le contenu de ssl.conf

<VirtualHost *:80>
  RewriteEngine on
  RewriteCond %{HTTP:X-Forwarded-Proto} =http
  RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
  <Proxy *>
    Order Allow,Deny
    Allow from all
  </Proxy>
  ProxyPass / http://localhost:8080/ retry=0
  ProxyPassReverse / http://localhost:8080/
  ProxyPreserveHost on

  ErrorLog /var/log/httpd/elasticbeanstalk-error_log
</VirtualHost>

Espérons que cela aidera.

sur elastic beanstalk vous pouvez simplement ajouter votre configuration on afin que AWS écrive leur, il vous permettra d'écraser la configuration du serveur web et soumettre votre propre configuration.

il suffit d'ajouter le fichier suivant sous le chemin: .ebextensions\httpd\conf.d

contenu du fichier:

<VirtualHost *:80>
   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}

   <Proxy *>
     Order deny,allow
     Allow from all
   </Proxy>

   ProxyPass / http://localhost:8080/ retry=0
   ProxyPassReverse / http://localhost:8080/
   ProxyPreserveHost on

   ErrorLog /var/log/httpd/elasticbeanstalk-error_log

</VirtualHost>

Le".ebextensions' est le dossier de configuration standard dans AWS et le reste pointe juste vers quel dossier et le dossier vous souhaitez remplacer. Si le fichier ou le dossier n'existe pas simple les créer.

j'ai eu du mal à comprendre cela, alors après avoir trouvé une solution, j'ai écrit une explication détaillée de ma solution pour, Je l'espère, aider quelqu'un d'autre. Ceci est spécifique à Tomcat 8, Apache2, et L'application de démarrage à ressort. Il y a vraiment des exemples utiles ebextension dans les AWS labs GitHub .

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

1. créer un fichier à / src/main/webapp/.ebextensions/httpd / conf.d / elasticbeanstalk.conf
2. Ajouter réécrire conds/règles de l'attention à inclure "LoadModule rewrite_module modules/mod_rewrite.donc,"
3. Deploy to AWS EBS

voici un exemple de Botte à ressort app .

j'ai les configurations suivantes pour elastic beanstalk (64bit Amazon Linux 2016.09 v2.3.1 Exécution Tomcat 8 Java 8). J'ai créé un répertoire .ebextensions et a ajouté une .config fichier YAML avec les conditions de réécriture

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

1. parce que" si "l'état est inconnu
2. à cause D'Apache 2.2 Je n'ai pas mod_rewrite.donc inclus dans mon httpd.fichier conf

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

troisième solution essayée était d'ajouter " exécuter.config" et " ssl_rewrite.conf" fichiers de sous ".ebextendsion " directory.

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 " conf.d " direcotry mais rediriger du http vers https ne fonctionne pas.

la seule solution qui ait fonctionné pour moi a été d'ajouter les lignes suivantes dans le document" /etc/httpd/conf.d / elasticbeanstalk / 00_application.conf "

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

mais c'est une solution temporaire et si une machine est remplacée, ma redirection https disparaît.

Pourquoi ne pas simplement mettre un .htaccess dans le dossier racine? De cette façon, vous pouvez simplement le tester et le déboguer. Et si vous l'incluez dans le .zip, il se déploiera automatiquement sur toutes les instances à nouveau.

utiliser 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 vieille maintenant. La réponse D'un Paul est en fait la bonne réponse. Le lien fourni dans sa réponse est par AWS (donc c'est la méthode recommandée pour outrepasser votre configuration Apache pour faire 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, alors ajouter le .dossier ebextensions à l'intérieur de l'un des votre application web ne va pas fonctionner. Vous remarquerez Qu'aucune des configurations que vous avez spécifiées n'est écrite ou créée. Si vous déployez de multiples applications Web sur L'environnement Elastic Beanstalk, alors vous aurez besoin de lire cet article de AWS Java Tomcat Déployer Plusieurs fichiers WAR sur Elastic Beanstalk

en général, vous aurez besoin de la structure suivante avant de lancer la commande eb pour déployer les fichiers de guerre:

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

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

J'espère que ça aidera quelqu'un d'autre.

nous l'avons résolu sur notre arrière-plan en manipulant X-Forwarded-Proto correctement.

C'est notre configuration de Grails mais cela vous aidera avec 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 deux autres réponses à cette question https://stackoverflow.com/a/43026082/8775205 , https://stackoverflow.com/a/42035023/8775205 . Pour les utilisateurs de la botte de printemps qui déploient leurs services sur AWS avec ELB, et qui ont besoin d'un guide étape par étape, vous pouvez ajouter 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 à la suivante. Remarqué que j'ai mon tester le site avec une seule instance, donc j'ajoute une condition pour l'exclure.

<VirtualHost *:80>
   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}

   <Proxy *>
     Order deny,allow
     Allow from all
   </Proxy>

   ProxyPass / http://localhost:8080/ retry=0
   ProxyPassReverse / http://localhost:8080/
   ProxyPreserveHost on

   ErrorLog /var/log/httpd/elasticbeanstalk-error_log

</VirtualHost>

Après cela, n'oubliez pas d'ajouter une "ressource" sous maven-guerre-plugin dans votre pom.xml afin de récupérer la configuration ci-dessus.

<plugin>
     <groupId>org.apache.maven.plugins</groupId>  
     <artifactId>maven-war-plugin</artifactId>  
     <configuration>  
         <webResources>
             <resource>  
               <!-- some other resource configured by yourself-->
             </resource> 
             <resource>
                <directory>src/main/webapps/.ebextensions</directory>
                 <targetPath>.ebextensions</targetPath>
                 <filtering>true</filtering>
             </resource> 
         </webResources>  
     </configuration>  
     <version>2.1.1</version>
 </plugin>

enfin commit et push votre code, attendez AWS codebuild et codepipeline pour récupérer votre code à partir de votre dépôt et de déployer à l'environnement beanstalk, ou tout simplement pack votre projet dans un fichier de guerre et de le télécharger à votre AWS beanstalk environment

AWS n'accepte pas unserscores (_) dans les en-têtes, alors que nous pouvons utiliser ( -), donc supprimer les underscores des variables d'en-tête, exemple: - header_var_val = "une certaine valeur" remplacer par headervarval = "une certaine valeur" . Il fonctionne pour moi.

Juste au cas où quelqu'un est toujours de la difficulté:

j'ai lutté pendant un certain temps et finalement, j'ai trouvé un GitHub (de L'équipe AWS) avec toutes les configs AWS et l'exemple ci-dessous fonctionne pour la redirection HTTP>HTTPS pour Apache 2.2. (Pour les configs pour Apache 2.4 et Nginx, voir le lien ci-dessous).

Apache 2.2

1. créez un fichier dans le répertoire racine de votre application: YOUR_PROJECT_ROOT/.ebextensions/httpd / conf.d / elasticbeanstalk.conf (En cas d'utilisation D'IntelliJ / Java, assurez-vous qu'il va ajouté à la finale .Artefact de guerre)

2. ajouter les lignes suivantes pour activer la redirection dans l'hôte virtuel:

   <VirtualHost *:80>
       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}
   
       <Proxy *>
           Order deny,allow
           Allow from all
       </Proxy>
   
       ProxyPass / http://localhost:8080/ retry=0
       ProxyPassReverse / http://localhost:8080/
       ProxyPreserveHost on
   
       ErrorLog /var/log/httpd/elasticbeanstalk-error_log
   </VirtualHost>
   

pour plus d'exemples pour Apache 2.4 et Nginx veuillez visiter ce dépôt GitHub:

https://github.com/awsdocs/elastic-beanstalk-samples/tree/master/configuration-files/aws-provided/security-configuration/https-redirect/java-tomcat

en outre, il y a beaucoup plus de configuration utile et des exemples disponibles.

concerne

si vous utilisez un environnement de chargement équilibré, vous pouvez suivre les instructions pour configuration de HTTPS pour votre environnement élastique AWS et désactiver le port HTTP à la fin.

notez qu'actuellement le niveau D'utilisation libre de L'AWS inclut le même nombre d'heures pour un équilibrage de charge élastique (ELB) que pour une micro Instance 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 appelé wsgi.conf qui sera placé dans le dossier de base de votre application

3. modifier la version locale de wsgi.conf et ajouter les règles de redirection suivantes dans les balises < VirtualHost> < / VirtualHost>

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

4. changer le "/ statut" à n'importe quelle page que vous utilisez comme un bilan de santé page.

5. Enregistrer le fichier

6. éditez votre < app>.fichier conf à l'intérieur de votre . ebextensions répertoire pour ajouter un conteneur de commande 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éployer le code.

8. la version déployée de wsg.conf dans /etc/httd/conf.d / wsgi.conf va maintenant inclure les règles de redirection nécessaires.

il devrait fonctionner et le fichier sera correctement mis à jour pour chaque déploiement. La seule chose à surveiller est si Amazon change sa base wsgi.conf contenu du fichier dans l'avenir, votre copie peut ne plus fonctionner.

Autor rickchristianson