Passer au contenu principal

Déploiement sur Kubernetes

Déployez Casdoor dans Kubernetes (k8s)​

Nous fournissons un exemple de base pour déployer Casdoor dans un cluster Kubernetes. Dans le dossier racine de Casdoor, vous trouverez un fichier nommé "k8s.yaml". Ce fichier contient un exemple de configuration pour déployer Casdoor dans Kubernetes, incluant un déploiement et un service.

Avant de commencer le déploiement, assurez-vous d'avoir modifié le fichier conf/app.conf afin que Casdoor puisse se connecter à la base de données avec succès et que la base de données elle-même soit en fonctionnement. De plus, assurez-vous que Kubernetes puisse télécharger les images nécessaires.

Pour déployer Casdoor, exécutez la commande suivante :

kubectl apply -f k8s.yaml

Vous pouvez vérifier l'état du déploiement en exécutant la commande kubectl get pods.

Voici le contenu de k8s.yaml :

# this is only an EXAMPLE of deploying casddor in kubernetes
# please modify this file according to your requirements
apiVersion: v1
kind: Service
metadata:
  #EDIT IT: if you don't want to run casdoor in default namespace, please modify this field
  #namespace: casdoor
  name: casdoor-svc
  labels:
    app: casdoor
spec:
  #EDIT IT: if you don't want to run casdoor in default namespace, please modify this filed
  type: NodePort
  ports:
    - port: 8000
  selector:
    app: casdoor
---
apiVersion: apps/v1
kind: Deployment
metadata:
  #EDIT IT: if you don't want to run casdoor in default namespace, please modify this field
  #namespace: casdoor
  name: casdoor-deployment
  labels:
    app: casdoor
spec:
  #EDIT IT: if you don't use redis, casdoor should not have multiple replicas
  replicas: 1
  selector:
    matchLabels:
      app: casdoor
  template:
    metadata:
      labels:
        app: casdoor
    spec:
      containers:
        - name: casdoor-container
          image: casbin/casdoor:latest
          imagePullPolicy: Always
          ports:
            - containerPort: 8000
          volumeMounts:
            # the mounted directory path in THE CONTAINER
            - mountPath: /conf
              name: conf
          env:       
            - name: RUNNING_IN_DOCKER
              value: "true"
      #if you want to deploy this in real prod env, consider the config map
      volumes:
        - name: conf
          hostPath:
            #EDIT IT: the mounted directory path in THE HOST
            path: /conf

Veuillez noter que ce fichier est seulement un exemple. Vous pouvez effectuer diverses modifications selon vos besoins, telles que l'utilisation d'un autre espace de noms, type de service, ou un ConfigMap pour monter le fichier de configuration. L'utilisation d'un ConfigMap est une approche recommandée dans Kubernetes pour monter des fichiers de configuration dans un environnement de production.

Exposing Casdoor with Ingress​

Once Casdoor is deployed, you typically want to expose it externally. There are several approaches to handle authentication for your applications:

Direct Ingress Access​

For simple setups where you want to expose Casdoor itself, create an Ingress resource:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: casdoor-ingress
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  ingressClassName: nginx
  rules:
  - host: auth.yourdomain.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: casdoor-svc
            port:
              number: 8000
  tls:
  - hosts:
    - auth.yourdomain.com
    secretName: casdoor-tls-secret

Your applications can then integrate with Casdoor using the SDK or OAuth 2.0/OIDC protocols directly. This is the recommended approach for most use cases as it gives you full control over the authentication flow in your application code.

Authentication with ingress-nginx auth annotations​

While ingress-nginx provides external authentication capabilities through annotations, this approach has significant limitations when used with OAuth2/OIDC providers like Casdoor. The nginx.ingress.kubernetes.io/auth-url annotation is designed for simple token validation endpoints, not for complete OAuth2 flows that require redirects and session management.

For protecting applications at the ingress level, you should use oauth2-proxy or similar authentication proxies. These tools handle the complete OAuth2/OIDC flow including:

  • Initiating the login redirect to Casdoor
  • Handling the OAuth2 callback with authorization codes
  • Managing user sessions with cookies
  • Token refresh and validation

Here's how to deploy oauth2-proxy alongside your application:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: oauth2-proxy
spec:
  replicas: 1
  selector:
    matchLabels:
      app: oauth2-proxy
  template:
    metadata:
      labels:
        app: oauth2-proxy
    spec:
      containers:
      - name: oauth2-proxy
        image: quay.io/oauth2-proxy/oauth2-proxy:v7.5.1
        args:
        - --provider=oidc
        - --oidc-issuer-url=https://auth.yourdomain.com
        - --client-id=YOUR_CLIENT_ID
        - --client-secret=YOUR_CLIENT_SECRET
        - --redirect-url=https://app.yourdomain.com/oauth2/callback
        - --cookie-secret=RANDOM_SECRET_32_CHARS
        - --email-domain=*
        - --upstream=http://your-app-service:8080
        - --http-address=0.0.0.0:4180
        ports:
        - containerPort: 4180
---
apiVersion: v1
kind: Service
metadata:
  name: oauth2-proxy-svc
spec:
  ports:
  - port: 4180
    targetPort: 4180
  selector:
    app: oauth2-proxy
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: app.yourdomain.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: oauth2-proxy-svc
            port:
              number: 4180
  tls:
  - hosts:
    - app.yourdomain.com
    secretName: app-tls-secret

This approach ensures proper OAuth2/OIDC flow handling while keeping your application protected at the ingress layer.

Security Considerations​

When deploying authentication in Kubernetes:

  • Always use HTTPS/TLS - OAuth2 requires secure connections. Configure TLS certificates for your ingress resources using cert-manager or similar tools.
  • Secure sensitive values - Store client secrets, cookie secrets, and other sensitive data in Kubernetes Secrets, not in plain ConfigMaps or deployment manifests.
  • Use proper RBAC - Limit access to authentication configurations and secrets using Kubernetes RBAC policies.
  • Session management - For production deployments with multiple replicas, configure oauth2-proxy to use Redis for session storage to ensure sessions work across pod restarts and multiple instances.