Come forzare https su beanstalk elastico?

Non riesco a forzare https sul livello di utilizzo libero di beanstalk elastico.

Ho provato il seguente suggerimento su Come forzare https su beanstalk elastico Amazon senza fallire il controllo dello stato

Usando questa regola di riscrittura di Apache

RewriteEngine On RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteCond %{REQUEST_URI} !^/status$ RewriteCond %{REQUEST_URI} !^/version$ RewriteCond %{REQUEST_URI} !^/_hostmanager/ RewriteRule . https://%{SERVER_NAME}%{REQUEST_URI} [L,R] 

Quando provo a farlo, le richieste http non vengono reindirizzate su https come vorrei. Invece, la pagina http viene caricata normalmente. Ho anche provato a usare l’intestazione X-Forwarded-Port con lo stesso risultato.

Ho anche provato la seguente regola di riscrittura

 RewriteCond %{SERVER_PORT} 80 RewriteRule . https://%{SERVER_NAME}%{REQUEST_URI} [L,R] 

E questa regola provoca un ciclo di reindirizzamento. Quindi sembrerebbe che le regole di riscrittura dell’apache non riprendano le intestazioni di Elastic Load Balancer X-Forwarded-Port e X-Forwarded-Proto, ma anche un ciclo di reindirizzamento non è quello che sto andando per entrambi.

Per favore aiuto. Sono nuovo di AWS, Elastic Beanstalk e non conosco molto bene le regole di Apache. Non sono sicuro di dove andare da qui. Grazie.

Questa risposta presuppone che sia già stato abilitato https nel gruppo di sicurezza del servizio di bilanciamento del carico, aggiunto il certificato SSL al servizio di bilanciamento del carico, aggiunto 443 alle porte inoltrate dal servizio di bilanciamento del carico e puntato il proprio nome di dominio nell’ambiente Elastic Beanstalk con Route 53 (o servizio DNS equivalente).

NOTA: questa risposta è per gli ambienti Elastic Beanstalk che utilizzano Apache. Potrebbe anche non funzionare per una distribuzione basata su finestra mobile.

Tutto quello che devi fare è aggiungere quanto segue a uno dei tuoi file .config nella directory .ebextensions del tuo progetto :

 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]  

Spiegazione

Questo è moderatamente diretto al di fuori di Elastic Beanstalk. Di solito si aggiunge una regola di riscrittura di Apache come la seguente:

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

O, se dietro un bilanciamento del carico, come siamo in questo caso:

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

Tuttavia, queste configurazioni funzionano solo all’interno di un blocco . La modifica di RewriteCond in un blocco consente di funzionare correttamente al di fuori di un blocco , consentendoci di inserire in un file di configurazione Apache autonomo. Nota che l’installazione standard di Apache su CentOS (inclusa l’installazione su ElasticBeanstalk) include tutti i file che corrispondono a /etc/httpd/conf.d/*.conf , che corrisponde al percorso del file in cui stiamo archiviando questo file.

La parte della condizione -n '%{HTTP:X-Forwarded-Proto}' impedisce al reindirizzamento se non si è dietro un bilanciatore del carico, consentendo di avere una configurazione condivisa tra un ambiente di produzione con un servizio di bilanciamento del carico e https, e un ambiente di staging che è a istanza singola e non ha https. Questo non è necessario se si stanno utilizzando load balancer e https su tutti gli ambienti, ma non fa male averlo.

Cattive soluzioni che ho visto

Ho visto molte cattive soluzioni a questo problema, e vale la pena esaminarle per capire perché questa soluzione sia necessaria.

  1. Usa Cloudfront: alcune persone suggeriscono di utilizzare l’impostazione Cloudfront non in cache davanti a Elastic Beanstalk per eseguire il reindirizzamento da HTTP a HTTPS. Questo aggiunge un servizio completamente nuovo (aggiungendo così complessità) che non è esattamente appropriato (Cloudfront è un CDN, non è lo strumento giusto per forzare HTTPS su contenuti a contenuto intrinsecamente dinamico). La configurazione di Apache è la normale soluzione a questo problema e Elastic Beanstalk utilizza Apache, quindi questo è il modo in cui dovremmo andare.

  2. SSH nel server e …: questo è completamente antitetico al punto di Elean Beanstalk e ha così tanti problemi. Qualsiasi nuova istanza creata dalla scalabilità automatica non avrà la configurazione modificata. Qualsiasi ambiente clonato non avrà la configurazione. Qualsiasi numero di un ragionevole insieme di modifiche all’ambiente cancellerà la configurazione. Questa è solo una ctriggers idea.

  3. Sovrascrivi la configurazione di Apache con un nuovo file: questo sta entrando nel reame giusto della soluzione, ma ti lascia un incubo di manutenzione se Elastic Beanstalk cambia aspetti della configurazione del server (cosa che potrebbero fare molto bene). Vedi anche i problemi nel prossimo articolo.

  4. Modifica dynamicmente il file di configurazione di Apache per aggiungere poche righe: questa è una buona idea. I problemi con questo sono che non funzionerà se Elastic Beanstalk cambia mai il nome del loro file di configurazione di Apache predefinito e che questo file può essere sovrascritto quando meno te lo aspetti: https://forums.aws.amazon.com/thread .jspa? threadID = 163.369

EDIT: Mentre amo questa risposta, ora è molto vecchia . AWS ha creato nuovi servizi (come Certificate Manager ) che rendono obsoleta una parte di questa risposta. Inoltre, l’uso della cartella .ebextensions con Apache è un modo più semplice per gestire questo reindirizzamento come spiegato sopra.

Se stai ospitando il tuo sito Web su S3, alcune parti di questa risposta potrebbero comunque esserti utili.


Questo ha funzionato per me:

  1. Carica il certificato in AWS utilizzando il comando della console aws . La struttura di comando è:

     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. Nell’applicazione Elastic Beanstalk, vai su Configurazione -> Livello di rete -> Carica bilanciamento e fai clic sull’icona a forma di ingranaggio .

  3. Selezionare Porta listener sicura come 443 . Seleziona Protocollo come HTTPS . Seleziona il CERTIFICATE_NAME dal passaggio 2 per l’ID del certificato SSL . Salva la configurazione.

  4. Vai alla tua console . Fai clic su Istanze EC2 . Fai clic su Load Balancers . Fare clic tra i bilanciatori del carico. Fare clic su Istanze e scorrere verso il basso per visualizzare le istanze EC2 assegnate a tale servizio di bilanciamento del carico. Se l’istanza EC2 ha lo stesso nome dell’URL dell’applicazione (o qualcosa di simile), prendere nota del nome DNS per il bilanciamento del carico. Dovrebbe essere nel formato awseb-e-...

  5. Torna alla tua console . Fai clic su CloudFront . Fai clic su Crea distribuzione . Seleziona una distribuzione Web .

  6. Imposta la distribuzione. Impostare il nome del dominio di origine sul nome DNS del bilanciamento del carico trovato nel passaggio 5 . Impostare il criterio del protocollo Viewer per redirect HTTP a HTTPS . Imposta le stringhe di interrogazione in avanti su . Imposta Nomi di dominio alternativi (CNAME) negli URL che desideri utilizzare per la tua applicazione. Imposta il certificato SSL sul CERTIFICATE_NAME hai caricato nel passaggio 2 . Crea la tua distribuzione.

  7. Fai clic sul nome della tua distribuzione in CloudFront. Fai clic su Origini , seleziona la tua origine e fai clic su Modifica . Assicurarsi che il criterio del protocollo di origine sia Match Viewer . Torna indietro. Fai clic su Behaviors , seleziona la tua origine e fai clic su Modifica . Cambia le intestazioni in avanti nella whitelist e aggiungi l’ host . Salvare.

Nota: ho scritto anche una guida più lunga .

Il più upvoted non funziona per me .. la direttiva funziona solo con Apache 2.4+, ma ElasticBeanstalk ha la versione 2.2.x.

Quindi, seguendo lo stesso consiglio di cui sopra. Crea un file chiamato .ebextensions / https_rewrite.config con il seguente contenuto

 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] 

Questo sembra funzionare per me.

Su come creare questo file nel tuo file WAR, vedi questa risposta

Modifica: la soluzione Zags è più generale e corretta. Lo raccomando sopra il mio (che è specifico per un env python)

Ecco una soluzione pulita e veloce che ho trovato che evita l’hacking wsgi.conf o l’utilizzo di CloudFront

Nel tuo .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]  

Mi sembra troppo facile, ma sembra funzionare bene.

Si noti inoltre che sto reindirizzando esplicitamente HTTP anziché “non HTTPS”.

È lavoro per me con il prossimo comando:

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

e senza il controllo https:

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

Sembra che ELB modifichi il valore di X-Forwarded-Proto su http (anche su protocollo TCP).

Nessuna delle risposte di cui sopra ha funzionato per me, ma alcuni mi hanno aiutato a capire la risposta che ha funzionato per me Inoltre ho trovato l’URL qui sotto che ha aiutato http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/java-tomcat -platform.html

Ho creato la struttura del file menzionata nell’url sopra per modificare 2 file httpd.conf 00_application.conf

copia l’intero httpd.conf dalla tua istanza e inseriscilo nel tuo codice sotto .ebextention sotto la struttura della cartella menzionata nel link precedente. Quindi aggiungi semplicemente la riga sottostante a quel file nel tuo progetto

 LoadModule rewrite_module modules/mod_rewrite.so 

Fai lo stesso con 00_application.conf, copialo dalla tua istanza e inseriscilo nella tua codebase sotto .ebextention sotto httpd / conf.d / elasticbeanstalk / 00_application.conf Ora modifica questo file e aggiungi il sotto tra VirtualHost

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

Ora distribuisci il tuo codice dovrebbe funzionare.

Sto cercando di redirect un beanstalk elastico con loadbalancer nel 2018. Nessuna delle risposte di cui sopra funziona nel mio ambiente. Diversi problemi che ho rilevato:

  1. Stavo cercando la risposta più votata, ma il mio tomcat è la versione 2.7. Non supporta

  2. Stavo usando container_commands e ho copiato l’impostazione 00_applications. AWS semplicemente lo ignora.

Così finalmente ho capito lavorando a questo: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/java-tomcat-proxy.html

Ecco cosa faccio:

Ho ricreato la struttura delle cartelle:

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

E poi questo è il contenuto di 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  

Spero che questo ti sia d’aiuto.

Su beanstalk elastico puoi semplicemente aggiungere la tua configurazione in modo che AWS sovrascriva i propri, ti permetterà di sovrascrivere la configurazione del server web e inviare la tua configurazione.

Basta aggiungere il seguente file sotto il percorso: .ebextensions \ httpd \ conf.d

Contenuto del file:

  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  

“.Ebextensions” è la cartella di configurazione standard in AWS e il resto punta solo al file e alla cartella che desideri sovrascrivere. Se il file o la cartella non esiste, basta crearli.

Ho avuto un momento difficile a pensarlo così, dopo che ho trovato una soluzione, ho scritto una spiegazione dettagliata della mia soluzione per aiutare eventualmente qualcun altro. Questo è specifico per l’app Tomcat 8, Apache2 e Spring Boot. Ci sono esempi di ebextension davvero utili nel github dei laboratori AWS .

Riepilogo di ciò che ha funzionato per me:

  1. Creare un file in /src/main/webapp/.ebextensions/httpd/conf.d/elasticbeanstalk.conf
  2. Aggiungi rewrite conds / rules facendo attenzione a includere “LoadModule rewrite_module modules / mod_rewrite.so”
  3. Distribuire su AWS EBS

Ecco un esempio di app Spring Boot .

Ho le seguenti configurazioni per beanstalk elastico (64 bit Amazon Linux 2016.09 v2.3.1 con Tomcat 8 Java 8). Ho creato una directory .ebextensions e aggiunto un file YAML .config con le condizioni di riscrittura

La soluzione di Zagas descritta sopra (che è molto complessa) non funziona per me.

  1. Perché la condizione “Se” è sconosciuta
  2. A causa di Apache 2.2 non ho mod_rewrite.so incluso nel mio file httpd.conf

Questa soluzione ha più senso per me, ma anche questo non funziona. Non succede nulla e non riesco a vedere il file “ssl_rewrite.conf” nella directory “conf.d”.

Terza soluzione provata è stata quella di aggiungere i file “run.config” e “ssl_rewrite.conf” nella directory “.ebextendsion”.

run_config contiene

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

ssl_rewrite.conf contiene

 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 viene creato sotto la directory “conf.d”, ma il reindirizzamento da http a https non funziona.

L’unica soluzione funzionante per me era aggiungere le seguenti righe in “/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] ......  

ma questa è una soluzione temporanea e se una macchina viene sostituita il mio reindirizzamento https è sparito.

Perché non metti semplicemente un file .htaccess nella cartella principale? In questo modo puoi semplicemente testarlo e eseguirne il debug. E se lo includi in .zip, verrà automaticamente distribuito su tutte le istanze.

Basta usare .htaccess :

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

Si prega di notare che la risposta più votata è un po ‘vecchia ora. La risposta di A Paul è in realtà la risposta corretta. Il collegamento fornito nella sua risposta è da AWS (quindi è il metodo consigliato per sovrascrivere la configurazione di Apache per effettuare il reindirizzamento da HTTP a HTTPS quando si esegue l’applicazione su Elastic Beanstalk).

C’è una cosa molto importante da notare. Se stai distribuendo più di una app Web, l’aggiunta della cartella .ebextensions all’interno di una delle tue app Web non funzionerà. Noterai che Non delle configurazioni specificate sono state scritte o create. Se si stanno distribuendo più applicazioni Web in ambiente Elastic Beanstalk, sarà necessario leggere questo articolo di AWS Java Tomcat Distribuire più file WAR su Elastic Beanstalk

In generale, è necessario avere la seguente struttura prima di eseguire il comando eb per distribuire i file WAR:

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

se la cartella .ebextentions esiste all’interno di ciascun file WAR, si noterà che è completamente ignorata e che non verranno eseguite modifiche alla configurazione.

Spero che questo aiuti qualcun altro.

L’abbiamo risolto sul nostro backend gestendo correttamente X-Forwarded-Proto .

Questa è la nostra configurazione di Grails ma ti aiuterà con l’idea:

  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'] ] 

Per estendere altre due risposte a questa domanda https://stackoverflow.com/a/43026082/8775205 , https://stackoverflow.com/a/42035023/8775205 . Per gli utenti di avvio primaverili che distribuiscono i loro servizi su AWS con ELB e che necessitano di una guida dettagliata, è ansible aggiungere un file conf. **** in src / main / webapp / .ebextensions / httpd / conf.d / nel progetto .

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

****. conf si presenta come il seguente. Notato che ho il mio sito di test con una singola istanza, quindi aggiungo una condizione per escluderla.

  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  

Dopo di ciò, ricorda di aggiungere una “risorsa” sotto il plugin maven-war nel tuo pom.xml per raccogliere la configurazione di cui sopra.

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

Infine, esegui il commit e invia il codice, attendi il codebuild e la codepipeline AWS per prelevare il codice dal repository e distribuirlo nell’ambiente beanstalk, o semplicemente impacchetta il tuo progetto in un file war e caricalo nell’ambiente beanstalk di AWS

AWS non accetta i unserscores (_) nei headders, mentre possiamo usare (-), So Remove underscore dalle variabili dell’header, esempio: – header_var_val = “qualche valore” sostituirlo con headervarval = “qualche valore” . Per me funziona.

Se si utilizza un ambiente Load Balanced, è ansible seguire le istruzioni per la configurazione di HTTPS per l’ambiente AWS Elastic Beanstalk e, al termine, distriggersre la porta HTTP.

Si noti che attualmente il livello di utilizzo gratuito di AWS include la stessa quantità di ore per un Elastic Load Balancing (ELB) come per un’Istanza Micro EC2.

questa è una soluzione facile

  1. ssh nella tua istanza EC2
  2. copia il contenuto di /etc/httpd/conf.d/wsgi.conf in un file locale chiamato wsgi.conf che verrà inserito nella cartella di base dell’applicazione
  3. Modifica la versione locale di wsgi.conf e aggiungi le seguenti regole di reindirizzamento all’interno dei tag

     RewriteEngine On RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteRule !/status https://%{SERVER_NAME}%{REQUEST_URI} [L,R=301] 
  4. Cambia lo “/ status” in qualunque pagina stai usando come pagina di controllo sanitario .

  5. Salva il file
  6. Modifica il tuo file .conf all’interno del tuo. directory di ebextensions per aggiungere un comando container per copiare questa versione di wsgi.conf sulla versione di 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. Distribuire il codice.

  8. La versione distribuita di wsg.conf in /etc/httd/conf.d/wsgi.conf includerà ora le necessarie regole di reindirizzamento.

Dovrebbe funzionare e il file verrà aggiornato correttamente per ogni distribuzione. L’unica cosa da tenere in considerazione è se Amazon cambierà il contenuto del file wsgi.conf di base in futuro, quindi la tua copia potrebbe non funzionare più.

Autore rickchristianson