dockware / dockware

Managed Shopware 6 Docker setups with dockware. Run any Shopware 6 version within minutes (locally) in Docker
https://dockware.io
MIT License
150 stars 48 forks source link

[AWS EKS] HTTPS doesnt work with exposed port 443 or 80 #203

Open tehseensajjad opened 7 months ago

tehseensajjad commented 7 months ago

Describe the bug I'm trying to host dockware/dev for my devs to develop against their REST API. We're using EKS in AWS. To host:

  1. Deployment that creates pods that expose 443
  2. Service that routes 443 to 443 on pod
  3. Ingress that creates exernal AWS loadbalancer to service port 443. TLS is terminated here, a ACM Certificate is attached to this load balancer. A subdomain example.company.com is bound to this loadbalancer.

Visiting https://example.company.com gives the following error: image

Tried changing the port to 80, which results in the following page image

Changes being:

  1. Deployment that creates pods that expose 80
  2. Service that routes 80 to 80 on pod
  3. Ingress that creates exernal AWS loadbalancer to service port 80.

To Reproduce Steps to reproduce the behavior:

Deployment:

---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: shopware
  name: shopware
  namespace: shopware
spec:
  replicas: 1
  selector:
    matchLabels:
      app: shopware
  template:
    metadata:
      labels:
        app: shopware
    spec:
      containers:
      - image: dockware/dev:6.5.7.3
        imagePullPolicy: IfNotPresent
        resources: {}
        name: dev
        ports:
        - name: web-ssl
          containerPort: 443
        env:
        - name: TZ
          value: Europe/London
        - name: SHOP_DOMAIN
          value: example.company.com
        - name: XDEBUG_ENABLED
          value: "1"
        - name: PHP_VERSION
          value: "8.1"
---
apiVersion: v1
kind: Service
metadata:
  name: shopware
  namespace: shopware
spec:
  selector:
    app: shopware
  ports:
  - port: 443
    targetPort: 443
    name: web
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/certificate-arn: <REDACTED>
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
  name: shopware
  namespace: shopware
spec:
  ingressClassName: alb
  rules:
  - http:
      paths:
      - backend:
          service:
            name: shopware
            port:
              number: 443
        path: /
        pathType: Prefix

Expected behavior As per documentation, exposing port 443 should make HTTPS work.

Desktop (please complete the following information):

boxblinkracer commented 6 months ago

Hi

i think its just a thing with HTTPS can you login into the administration -> sales channel and check if there is also a httpS domain properly configured?

that would help as first step i think

ssachtleben commented 2 months ago

I have the same issue. Is there really no possibility to enable https only?

@tehseensajjad did you find a solution?

@boxblinkracer it's not possible to access the admin area since all scripts / css are loaded via http and not working.

Edit: I managed to switch off the https redirect in our ALB and can access the admin area. However if I delete the http domain it will complain that the http domain is not configured even if access it via https. What else do I need to configure to load the assets from https? I'm using dockware/dev:6.5.8.10.

dhilgarth commented 2 months ago

@boxblinkracer : Could this hardcoded http in line 7 be the issue here? https://github.com/dockware/dockware/blob/master/template/assets/assets/shopware6/files/update_domain.sh.twig#L7

UPDATE: No it's not. See the answers from @m4djack and myself below for a fix

m4djack commented 1 month ago

Same issue here on ECS.

I have checked and tried with both https/http and removing http in admin storefront settings, but do not help. Tried the customer domain in docs, https://docs.dockware.io/development/custom-domains

m4djack commented 1 month ago

So after multiple hours I managed to get more to work with https bye adding this to the 000-default.conf on site-enabled on apache2:

<VirtualHost *:80>

    ServerAdmin local@dockware
    ServerName shopware.dontlikehttpsbydefault.com
    # Ensure the Rewrite module is enabled
    RewriteEngine On

    # Redirect HTTP to HTTPS using the X-Forwarded-Proto header
    RewriteCond %{HTTP:X-Forwarded-Proto} !https
    RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R=301,L]

    # Handle mixed content by explicitly marking resources as HTTPS
    Header always set Content-Security-Policy "upgrade-insecure-requests;"

    # Optional: You can also force HSTS
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

    ErrorLog /var/log/apache2/error.log
    AccessFileName .htaccess.watch .htaccess

    DocumentRoot /var/www/html/public

    <Directory /var/www/html/public>
        Options -Indexes
        AllowOverride All
        Require all granted
        CGIPassAuth On
    </Directory>
...
...
dhilgarth commented 1 month ago

@m4djack That's great info, thanks!

Based on it, I came up with the following Dockerfile which patches the original Dockware image accordingly:

FROM dockware/dev:6.5.8.10

RUN sudo sed -i '/<VirtualHost \*:80>/a ServerName ##server_name##\n RewriteEngine On\n RewriteCond %{HTTP:X-Forwarded-Proto} !https\n RewriteRule ^/?(.*) https://%{SERVER_NAME}/\$1 [R=301,L]\n Header always set Content-Security-Policy "upgrade-insecure-requests;"' /etc/apache2/sites-enabled/000-default.conf && \
    sudo sed -i '/000-default.conf/a sudo sed -i "s|##server_name##|\${SHOP_DOMAIN}|" /etc/apache2/sites-enabled/000-default.conf' /entrypoint.sh

(I left out the line that forces HSTS as this already is done by my reverse proxy)

driv commented 3 weeks ago

I've had a similar issues when trying to deploy Shopware behind a LoadBalancer with ssl termination on the LoadBalancer.

Client >-https-> LoadBalancer >-http-> Nginx >-http-> Shopware

I reported the issue to Shopware https://github.com/shopware/docker/issues/30

Apparently symfony is the one responsible to discover the correct domain. Is it possible to apply this configuration to Dockware? https://symfony.com/doc/current/deployment/proxies.html

When the application is behind a proxy (LoadBalancer, Nginx, etc.) it should ignore the port being used and trust the header. Is it possible to have Dockware use the X-Forwarded-* headers to determine the Shop?

LloenDBG commented 2 weeks ago

In my configuration the load balancer did not change the remote address nor set the X-Forwarded-* headers and I had to force symphony to use https requests everywhere by adding this to my nginx config

location ~ ^/index\.php$ {
    fastcgi_pass 127.0.0.1:9000;
    include fastcgi.conf;
    # Lie to Symfony about the protocol and port so that it generates the correct HTTPS URLs
    fastcgi_param SERVER_PORT "443";
    fastcgi_param HTTPS "on";
}

https://symfony.com/doc/current/deployment/proxies.html#overriding-configuration-behind-hidden-ssl-termination