Zum Hauptinhalt springen

Eigene Domain für den Object Storage

Standardmäßig sind Objekte unter https://Bucketname.s3.internet1.de/<key> erreichbar. Diese Anleitung zeigt drei Wege, stattdessen eine eigene Domain wie files.example.com zu verwenden.

VarianteAufwandEigenes TLS-Zertifikat für die DomainZusätzlicher Server nötig
A: CNAMEgeringnein¹nein
B: NGINX Reverse Proxymittelja (z. B. Let's Encrypt)ja
C: s3-proxymitteljaja

¹ Bei reinem CNAME präsentiert der Storage das Zertifikat für *.s3.internet1.de – HTTPS unter der eigenen Domain führt dadurch zu Zertifikatswarnungen. CNAME eignet sich daher primär für HTTP-Weiterleitungen oder in Kombination mit einem CDN, das TLS terminiert.

Variante A: CNAME-Eintrag​

Voraussetzung: Der Bucket-Name muss exakt der gewünschten Domain entsprechen (Bucket files.example.com), damit die Virtual-hosted-Zuordnung funktioniert.

  1. Bucket mit dem Namen files.example.com anlegen; Objekte, die öffentlich erreichbar sein sollen, entsprechend freigeben.
  2. Beim DNS-Anbieter einen CNAME setzen:
files.example.com.  300  IN  CNAME  files.example.com.s3.internet1.de.
  1. Test: http://files.example.com/pfad/objekt.jpg
Info

Für sauberes HTTPS unter eigener Domain Variante B oder C verwenden – oder ein CDN mit eigenem Zertifikat vorschalten.

Variante B: NGINX Reverse Proxy​

Ein eigener Server (z. B. centron Cloud-Server) terminiert TLS und reicht Anfragen an den Bucket weiter.

  1. DNS: A/AAAA-Record von files.example.com auf den Proxy-Server zeigen lassen.
  2. Zertifikat besorgen, z. B. certbot --nginx -d files.example.com.
  3. NGINX-Konfiguration /etc/nginx/sites-available/files.example.com:
server {
    listen 443 ssl http2;
    server_name files.example.com;

    ssl_certificate     /etc/letsencrypt/live/files.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/files.example.com/privkey.pem;

    # Optionaler Cache für ausgelieferte Objekte
    # proxy_cache_path /var/cache/nginx keys_zone=s3cache:10m max_size=10g; (im http-Block)

    location / {
        proxy_pass https://mein-bucket.s3.internet1.de/;
        proxy_set_header Host mein-bucket.s3.internet1.de;
        proxy_ssl_server_name on;

        # Interne S3-Header nicht an Clients durchreichen
        proxy_hide_header x-amz-request-id;
        proxy_hide_header x-amz-id-2;

        # Größere Uploads erlauben, falls PUT durchgereicht wird
        client_max_body_size 0;
    }
}

server {
    listen 80;
    server_name files.example.com;
    return 301 https://$host$request_uri;
}
  1. Aktivieren und neu laden:
ln -s /etc/nginx/sites-available/files.example.com /etc/nginx/sites-enabled/
nginx -t && systemctl reload nginx

Hinweis: In dieser Grundkonfiguration werden nur öffentlich lesbare Objekte ausgeliefert. Sollen private Objekte bereitgestellt werden, muss der Proxy Anfragen signieren – dafür eignet sich Variante C.

Variante C: s3-proxy​

s3-proxy ist ein leichtgewichtiger Proxy, der Anfragen selbst signiert und damit auch private Buckets unter eigener Domain zugänglich macht – inklusive optionaler Authentifizierung, Templates und Verzeichnislisten.

Beispiel per Docker Compose:

services:
  s3-proxy:
    image: oxynozeta/s3-proxy:latest
    ports:
      - "8080:8080"
    volumes:
      - ./config:/proxy/conf

./config/config.yaml:

targets:
  files:
    mount:
      path:
        - /
    bucket:
      name: mein-bucket
      region: 
      s3Endpoint: https://s3.internet1.de
      credentials:
        accessKey:
          env: S3_ACCESS_KEY
        secretKey:
          env: S3_SECRET_KEY

Zugangsdaten als Umgebungsvariablen übergeben und den Dienst hinter NGINX (Variante B, proxy_pass http://127.0.0.1:8080;) mit TLS veröffentlichen.

Empfehlung​

  • Öffentliche Assets, wenig Aufwand: Variante A (+ CDN für HTTPS)
  • Volle Kontrolle über TLS, Caching, Header: Variante B
  • Private Buckets unter eigener Domain: Variante C

Verwandte Themen​

Letztes Update am