Cette réponse suppose que vous avez déjà activé https dans le groupe de sécurité de l'équilibreur de charge, que vous avez ajouté le certificat SSL à l'équilibreur de charge, que les ports 80 et 443 sont transférés par l'équilibreur de charge et que vous avez pointé votre nom de domaine vers l'environnement Elastic Beanstalk avec Route 53 (ou un service DNS équivalent).
Option 1 : Faire la redirection avec Apache
Cela n'est possible que si vous êtes sur un environnement Elastic Beanstalk qui utilise Apache (les déploiements basés sur AWS Linux 2 peuvent être configurés pour utiliser Apache). Cela peut ne pas fonctionner pour un déploiement basé sur Docker.
Amazon Linux 2
La plupart des plateformes basées sur AWS Linux version 2 ont la possibilité de choisir Apache comme hôte de proxy. Cela peut être fait en allant dans "Configuration" > "Software" > "Contai". "Container Options" et en définissant le "Proxy Server" comme étant "Apache", ou en ajoutant ce qui suit à l'un de vos fichiers de configuration. .config fichiers dans .ebextensions :
option_settings:
aws:elasticbeanstalk:environment:proxy:
ProxyServer: apache
Une fois cela fait, ajoutez un fichier de configuration nommé .platform/httpd/conf.d/ssl_rewrite.conf à votre codebase ( Documents AWS pertinents ) avec le contenu suivant :
RewriteEngine On
<If "-n '%{HTTP:X-Forwarded-Proto}' && %{HTTP:X-Forwarded-Proto} != 'https'">
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
</If>
Amazon Linux 1
Tout ce que vous avez à faire est d'ajouter ce qui suit à l'une de vos pages Web .config dans le .ebextensions 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 relativement simple en dehors d'Elastic Beanstalk. On ajoute généralement une règle de réécriture Apache comme la suivante :
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
Ou, si derrière un équilibreur de charge, comme nous le sommes dans ce cas :
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
Toutefois, ces configurations ne fonctionnent que dans le cadre d'une <VirtualHost> bloc. La modification du RewriteCond à un <If> lui permet de fonctionner correctement en dehors d'une <VirtualHost> ce qui nous permet de le placer dans un fichier de configuration Apache autonome. Notez que la configuration standard d'Apache sur CentOS (y compris la configuration d'ElasticBeanstalk) inclut tous les fichiers correspondant à /etc/httpd/conf.d/*.conf qui correspond au chemin d'accès au fichier où nous stockons ce fichier.
En -n '%{HTTP:X-Forwarded-Proto}' une partie de la condition l'empêche de rediriger 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 préparation qui est une instance unique et n'a pas https. Cela n'est pas nécessaire si vous utilisez des équilibreurs de charge et https sur tous vos environnements, mais cela ne fait pas de mal de l'avoir.
Option 2 : Faire la redirection avec l'ALB
Cela n'est possible que si vous utilisez un équilibreur de charge d'applications. Amazon fournit des instructions sur la manière de procéder ici : https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/configuring-https-httpredirect.html
Tout ce que vous avez à faire est d'ajouter ce qui suit à l'une de vos pages Web .config dans le .ebextensions de votre projet pour remplacer l'écouteur http par une redirection :
Resources:
AWSEBV2LoadBalancerListener:
Type: AWS::ElasticLoadBalancingV2::Listener
Properties:
LoadBalancerArn:
Ref: AWSEBV2LoadBalancer
Port: 80
Protocol: HTTP
DefaultActions:
- Type: redirect
RedirectConfig:
Host: "#{host}"
Path: "/#{path}"
Port: "443"
Protocol: "HTTPS"
Query: "#{query}"
StatusCode: "HTTP_301"
Les mauvaises solutions que j'ai vues
J'ai vu beaucoup de mauvaises solutions à ce problème, et il vaut la peine de les passer en revue pour comprendre pourquoi cette solution est nécessaire.
-
Utilisez Cloudfront : Certaines personnes suggèrent d'utiliser une configuration Cloudfront sans cache en amont d'Elastic Beanstalk pour effectuer la redirection HTTP vers HTTPS. Cela ajoute un tout nouveau service (et donc une complexité supplémentaire) qui n'est pas vraiment approprié (Cloudfront est un CDN ; ce n'est pas le bon outil pour forcer le HTTPS sur un contenu essentiellement dynamique). La configuration Apache est la solution normale à ce problème et Elastic Beanstalk utilise Apache, donc c'est la voie à suivre.
-
SSH dans le serveur et... : Ceci est complètement contraire à l'objectif d'Elastic Beanstalk et pose de nombreux problèmes. Toute nouvelle instance créée par autoscaling n'aura pas la configuration modifiée. Tout environnement cloné n'aura pas la configuration. N'importe quel nombre d'un ensemble raisonnable de changements d'environnement effacera la configuration. C'est une très mauvaise idée.
-
Ecraser la configuration d'Apache avec un nouveau fichier : Cette solution se rapproche de la solution idéale, mais elle vous laisse avec un cauchemar de maintenance si Elastic Beanstalk modifie certains aspects de la configuration du serveur (ce qui peut très bien arriver). Voir aussi les problèmes dans l'article suivant.
-
Modifier dynamiquement le fichier de configuration d'Apache pour 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é au moment où vous vous y attendez le moins : https://forums.aws.amazon.com/thread.jspa?threadID=163369
