Apache Superset im Internet verfügbar machen

2024-09-20

In diesem Artikel wird beschrieben, wie Apache Superset im Internet verfügbar gemacht wird.

Hostnamenauswahl

Entscheiden Sie sich für einen Hostnamen für Superset.

Sofern Sie keinen benutzerdefinierten DNS-Namen verwenden, sollte dieser Hostname mit dem Muster übereinstimmen: <superset-instance-name>.<azure-region>.cloudapp.azure.com. Der Name der superset-instance-name muss innerhalb der Azure-Region eindeutig sein.

Beispiel: myuniquesuperset.westus3.cloudapp.azure.com
Rufen Sie ein TLS-Zertifikat für den Hostnamen ab, platzieren Sie es in Ihrem Key Vault und benennen Sie es als aks-ingress-tls. Erfahren Sie, wie Sie ein Zertifikat in einen Azure Key Vault einfügen.

Zugangskonfiguration

Die folgenden Anweisungen fügen eine zweite Authentifizierungsebene in Form eines OAuth-Autorisierungsproxys mit Oauth2Proxy hinzu. Diese Ebene bedeutet, dass keine nicht autorisierten Clients die Superset-Anwendung erreichen.

Fügen Sie ihrem Key Vault die folgenden geheimen Schlüssel hinzu.

Geheimer Name	Beschreibung
Kunden-ID	Ihre Azure-Dienstprinzipal-Client-ID. OAuth-Proxy erfordert, dass diese ID ein geheimer Schlüssel ist.
oauth2proxy-redis-password	Proxy-Cache-Kennwort. Das vom OAuth-Proxy verwendete Kennwort für den Zugriff auf die Back-End-Redis-Bereitstellungsinstanz auf Kubernetes. Generieren Sie ein sicheres Kennwort.
oauth2proxy-cookie-secret	32 Zeichen Geheimer Cookieschlüssel, der zum Verschlüsseln der Cookie-Daten verwendet wird. Dieser Geheimschlüssel muss 32 Zeichen lang sein.

Fügen Sie diese Rückrufe in die Azure AD-Anwendungskonfiguration von Superset hinzu.
- https://{{superset_hostname}}/oauth2/callback
  - für OAuth2-Proxy
- https://{{superset_hostname}}/oauth-authorized/azure
  - für Superset

Bereitstellung des Ingress-Nginx-Controllers im default-Namespace

helm install ingress-nginx-superset ingress-nginx/ingress-nginx \
--namespace default \
--set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-health-probe-request-path"=/healthz \
--set controller.config.proxy-connect-timeout="60" \
--set controller.config.proxy-read-timeout="1000" \
--set controller.config.proxy-send-timeout="1000" \
--set controller.config.proxy-buffer-size="'64k'" \
--set controller.config.proxy-buffers-number="8"

Ausführliche Anweisungen finden Sie hier in Azure-Anweisungen.

Anmerkung

Die Schritte für den Eingangs-nginx-Controller verwenden Kubernetes-Namespace ingress-basic. Dies muss mit dem default Namespace geändert werden. z. B. NAMESPACE=default

Erstellen Sie die TLS Secret Provider-Klasse.

In diesem Schritt wird beschrieben, wie das TLS-Zertifikat aus dem Key Vault gelesen und in einen Kubernetes-Geheimschlüssel umgewandelt wird, der von ingress verwendet werden soll:

Aktualisieren Sie die folgende yaml-Datei.

{{MSI_CLIENT_ID}} – Die Client-ID der verwalteten Identität, die dem Superset-Cluster zugewiesen ist ($MANAGED_IDENTITY_RESOURCE).
{{KEY_VAULT_NAME}} – Der Name des Azure Key Vault mit den geheimen Schlüsseln.
{{KEY_VAULT_TENANT_ID}} – Die ID-GUID des Azure-Mandanten, in dem sich der Key Vault befindet.

tls-secretprovider.yaml

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: azure-tls
spec:
  provider: azure
  # secretObjects defines the desired state of synced K8s secret objects
  secretObjects:
  - secretName: ingress-tls-csi
    type: kubernetes.io/tls
    data: 
    - objectName: aks-ingress-tls
      key: tls.key
    - objectName: aks-ingress-tls
      key: tls.crt
  parameters:
    usePodIdentity: "false"
    useVMManagedIdentity: "true"
    userAssignedIdentityID: "{{MSI_CLIENT_ID}}"
    # the name of the AKV instance
    keyvaultName: "{{KEY_VAULT_NAME}}"
    objects: |
      array:
        - |
          objectName: aks-ingress-tls
          objectType: secret
    # the tenant ID of the AKV instance
    tenantId: "{{KEY_VAULT_TENANT_ID}}"

Erstellen Sie die OauthProxy Secret Provider-Klasse.

Aktualisieren Sie die folgende yaml-Datei.

{{MSI_CLIENT_ID}} – Die Client-ID der verwalteten Identität, die dem Superset-Cluster zugewiesen ist ($MANAGED_IDENTITY_RESOURCE).
{{KEY_VAULT_NAME}} – Der Name des Azure Key Vault mit den geheimen Schlüsseln.
{{KEY_VAULT_TENANT_ID}} – Die GUID des Azure-Mandanten, in dem sich der Key Vault befindet.

oauth2-secretprovider.yaml

# This is a SecretProviderClass example using aad-pod-identity to access the key vault
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: oauth2-secret-provider
spec:
  provider: azure
  parameters:
    useVMManagedIdentity: "true" 
    userAssignedIdentityID: "{{MSI_CLIENT_ID}}"
    usePodIdentity: "false"              # Set to true for using aad-pod-identity to access your key vault
    keyvaultName: "{{KEY_VAULT_NAME}}"   # Set to the name of your key vault
    cloudName: ""                        # [OPTIONAL for Azure] if not provided, the Azure environment defaults to AzurePublicCloud
    objects: |
      array:
        - |
          objectName: oauth2proxy-cookie-secret
          objectType: secret
        - |
          objectName: oauth2proxy-redis-password
          objectType: secret
        - |
          objectName: client-id
          objectType: secret
        - |
          objectName: client-secret
          objectType: secret
    tenantId: "{{KEY_VAULT_TENANT_ID}}"  # The tenant ID of the key vault
  secretObjects:                             
  - secretName: oauth2-secret
    type: Opaque
    data:
    # OauthProxy2 Secrets
    - key: cookie-secret
      objectName: oauth2proxy-cookie-secret
    - key: client-id
      objectName: client-id
    - key: client-secret
      objectName: client-secret
    - key: redis-password
      objectName: oauth2proxy-redis-password
  - secretName: oauth2-redis
    type: Opaque
    data:
    - key: redis-password
      objectName: oauth2proxy-redis-password

Erstellen Sie die Konfiguration für den OAuth-Proxy.

Aktualisieren Sie die folgende yaml-Datei.

{{superset_hostname}} - der Internethostname, der in bei der Auswahl des Hostnamens gewählt wurde
{{tenant-id}} – Die ID-GUID des Azure-Mandanten, in dem Ihr Dienstprinzipal erstellt wurde.

Optional: aktualisieren Sie die E-Mail-Domains-Liste. Beispiel: email_domains = [ "microsoft.com" ]

oauth2-values.yaml

# Force the target Kubernetes version (it uses Helm `.Capabilities` if not set).
# This is especially useful for `helm template` as capabilities are always empty
# due to the fact that it doesn't query an actual cluster
kubeVersion:

# OAuth client configuration specifics
config:
  # OAuth client secret
  existingSecret: oauth2-secret
  configFile: |-
    email_domains = [ ]
    upstreams = [ "file:///dev/null" ]

image:
  repository: "quay.io/oauth2-proxy/oauth2-proxy"
  tag: "v7.4.0"
  pullPolicy: "IfNotPresent"

extraArgs: 
    provider: oidc
    oidc-issuer-url: https://login.microsoftonline.com/<tenant-id>/v2.0
    login-url: https://login.microsoftonline.com/<tenant-id>/v2.0/oauth2/authorize
    redeem-url: https://login.microsoftonline.com/<tenant-id>/v2.0/oauth2/token
    oidc-jwks-url: https://login.microsoftonline.com/common/discovery/keys
    profile-url: https://graph.microsoft.com/v1.0/me
    skip-provider-button: true

ingress:
  enabled: true
  path: /oauth2
  pathType: ImplementationSpecific
  hosts:
  - "{{superset_hostname}}"
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/proxy_buffer_size: 64k
    nginx.ingress.kubernetes.io/proxy_buffers_number: "8"
  tls:
  - secretName: ingress-tls-csi
    hosts:
     - "{{superset_hostname}}"

extraVolumes:
  - name: oauth2-secrets-store
    csi:
      driver: secrets-store.csi.k8s.io
      readOnly: true
      volumeAttributes:
        secretProviderClass: oauth2-secret-provider
  - name: tls-secrets-store
    csi:
      driver: secrets-store.csi.k8s.io
      readOnly: true
      volumeAttributes:
        secretProviderClass: azure-tls

extraVolumeMounts: 
  - mountPath: "/mnt/oauth2_secrets"
    name: oauth2-secrets-store
    readOnly: true
  - mountPath: "/mnt/tls-secrets-store"
    name: tls-secrets-store
    readOnly: true

# Configure the session storage type, between cookie and redis
sessionStorage:
  # Can be one of the supported session storage cookie/redis
  type: redis
  redis:
    # Secret name that holds the redis-password and redis-sentinel-password values
    existingSecret: oauth2-secret
    # Can be one of sentinel/cluster/standalone
    clientType: "standalone"

# Enables and configure the automatic deployment of the redis subchart
redis:
  enabled: true
  auth:
    existingSecret: oauth2-secret

# Enables apiVersion deprecation checks
checkDeprecation: true

Bereitstellen von OAuth-Proxyressourcen.

kubectl apply -f oauth2-secretprovider.yaml
kubectl apply -f tls-secretprovider.yaml
helm repo add oauth2-proxy https://oauth2-proxy.github.io/manifests
helm repo update
helm upgrade --install --values oauth2-values.yaml oauth2 oauth2-proxy/oauth2-proxy

Aktualisieren Sie die DNS-Bezeichnung in der zugeordneten öffentlichen IP.
1. Öffnen Sie Ihren Superset AKS Kubernetes-Cluster im Azure-Portal.
2. Wählen Sie im linken Navigationsbereich "Eigenschaften" aus.
3. Öffnen Sie den Link "Infrastrukturressourcengruppe".
4. Suchen Sie die öffentliche IP-Adresse mit den folgenden Tags:
```
{
  "k8s-azure-cluster-name": "kubernetes",
  "k8s-azure-service": "default/ingress-nginx-controller"
}
```
5. Wählen Sie in der linken Navigationsleiste der Öffentlichen IP "Konfiguration" aus.
6. Geben Sie die DNS-Namensbezeichnung mit der in der <superset-instance-name>Hostnamenauswahl definierten Bezeichnung ein.
Stellen Sie sicher, dass Ihr Eingangseingang für OAuth konfiguriert ist.

Führen Sie kubectl get ingress aus, um die beiden Ingresses azure-trino-superset und oauth2-oauth2-proxyanzuzeigen. Die IP-Adresse entspricht der öffentlichen IP aus dem vorherigen Schritt.

Ebenso sollten Sie beim Ausführen von kubectl get services sehen, dass ingress-nginx-controller einem EXTERNAL-IPzugewiesen wurde.

Tipp

Sie können http://{{superset_hostname}}/oauth2 öffnen, um zu testen, dass der OAuth-Pfad funktioniert.

Definieren Sie einen Eingangseingang, um Zugriff auf Superset bereitzustellen, leiten Sie jedoch alle nicht autorisierten Aufrufe an /oauthum.

Aktualisieren Sie die folgende yaml-Datei.

{{superset_hostname}} - der Internethostname, der in bei der Auswahl des Hostnamens gewählt wurde

ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/auth-signin: https://$host/oauth2/start?rd=$escaped_request_uri
    nginx.ingress.kubernetes.io/auth-url: http://oauth2-oauth2-proxy.default.svc.cluster.local:80/oauth2/auth
    nginx.ingress.kubernetes.io/proxy-buffer-size: 64k
    nginx.ingress.kubernetes.io/proxy-buffers-number: "8"
    nginx.ingress.kubernetes.io/rewrite-target: /$1
  generation: 1
  labels:
    app.kubernetes.io/name: azure-trino-superset
  name: azure-trino-superset
  namespace: default
spec:
  rules:
  - host: "{{superset_hostname}}"
    http:
      paths:
      - backend:
          service:
            name: superset
            port:
              number: 8088
        path: /(.*)
        pathType: Prefix
  tls:
  - hosts:
    - "{{superset_hostname}}"
    secretName: ingress-tls-csi

Stellen Sie Ihren Eingangsschritt bereit.
```
      kubectl apply -f ingress.yaml
```
Test.

Öffnen Sie https://{{superset_hostname}}/ in Ihrem Browser.

Fehlerbehebung beim Eingangsverkehr

Tipp

Führen Sie die folgenden Befehle aus, um das Ingress-Deployment zurückzusetzen:

kubectl delete secret ingress-tls-csi
kubectl delete secret oauth2-secret
helm uninstall oauth2-proxy
helm uninstall ingress-nginx-superset
kubectl delete ingress azure-trino-superset

Nach dem Löschen dieser Ressourcen müssen Sie diese Anweisungen von Anfang an neu starten.

Ungültiges Sicherheitszertifikat: Kubernetes Ingress Controller Gefälschtes Zertifikat

Dies führt zu einem TLS-Zertifikatüberprüfungsfehler in Ihrem Browser/Client. Um diesen Fehler anzuzeigen, inspizieren Sie das Zertifikat in einem Browser.

Die übliche Ursache für dieses Problem besteht darin, dass Ihr Zertifikat falsch konfiguriert ist:

Überprüfen Sie, ob Ihr Zertifikat in Kubernetes angezeigt wird: kubectl get secret ingress-tls-csi --output yaml
Überprüfen Sie, ob Ihr CN mit dem in Ihrem Zertifikat angegebenen CN übereinstimmt.
- Der CN-Mismatch wird im Eingangs-Pod protokolliert. Diese Protokolle können angezeigt werden, indem Sie kubectl logs <ingress pod> ausführen.
  
  Beispiel: kubectl logs ingress-nginx-superset-controller-f5dd9ccfd-qz8wc
Der CN-Mismatch-Fehler wird mit dieser Protokollzeile beschrieben.

SSL-Zertifikat "default/ingress-tls-csi" enthält keinen Common Name oder Subject Alternative Name für Server "{server name}": x509: Zertifikat ist gültig für {ungültiger Hostname}, nicht {tatsächlicher Hostname}

Host konnte nicht aufgelöst werden

Wenn der Hostname für die Superset-Instanz nicht aufgelöst werden kann, hat die öffentliche IP keinen Hostnamen zugewiesen. Ohne diese Zuordnung kann DNS den Hostnamen nicht auflösen.

Überprüfen Sie die Schritte im Abschnitt Aktualisieren der DNS-Bezeichnung in der zugehörigen öffentlichen IP.

404 / nginx

Der Nginx-Eingangscontroller kann superset nicht finden. Stellen Sie sicher, dass Superset bereitgestellt wird, indem Sie kubectl get services ausführen und überprüfen, ob ein superset Dienst vorhanden ist. Überprüfen Sie, ob der Back-End-Dienst in "ingress.yaml " mit dem dienstnamen übereinstimmt, der für Superset verwendet wird.

503 Dienst vorübergehend nicht verfügbar / nginx

Der Dienst wird ausgeführt, aber nicht zugänglich. Überprüfen Sie die Dienstportnummern und den Dienstnamen.

Freigeben über

Apache Superset im Internet verfügbar machen

Hostnamenauswahl

Zugangskonfiguration

Fehlerbehebung beim Eingangsverkehr

Ungültiges Sicherheitszertifikat: Kubernetes Ingress Controller Gefälschtes Zertifikat

Host konnte nicht aufgelöst werden

404 / nginx

503 Dienst vorübergehend nicht verfügbar / nginx

Zusätzliche Ressourcen