Saltar al contenido principal

Desplegando en Kubernetes

Desplegar Casdoor en Kubernetes (k8s)​

Proporcionamos un ejemplo básico de cómo desplegar Casdoor en un clúster de Kubernetes. En la carpeta raíz de Casdoor, encontrarás un archivo llamado "k8s.yaml". Este archivo contiene un ejemplo de configuración para desplegar Casdoor en Kubernetes, incluyendo un despliegue y un servicio.

Antes de iniciar el despliegue, asegúrate de haber modificado el archivo conf/app.conf para que Casdoor pueda conectarse a la base de datos con éxito y que la base de datos misma esté en funcionamiento. Además, asegúrate de que Kubernetes pueda descargar las imágenes necesarias.

Para desplegar Casdoor, ejecuta el siguiente comando:

kubectl apply -f k8s.yaml

Puedes verificar el estado del despliegue ejecutando el comando kubectl get pods.

Aquí está el contenido 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

Por favor, ten en cuenta que este archivo es solo un ejemplo. Puedes realizar varias modificaciones según tus requisitos, como usar un espacio de nombres diferente, tipo de servicio, o un ConfigMap para montar el archivo de configuración. Usar un ConfigMap es un enfoque recomendado en Kubernetes para montar archivos de configuración en un entorno de producción.

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.