메인 콘텐츠로 건너뛰기

쿠버네티스에 배포하기

쿠버네티스(k8s)에 Casdoor 배포하기​

우리는 쿠버네티스 클러스터에 Casdoor를 배포하는 기본 예제를 제공합니다. Casdoor의 루트 폴더에서 'k8s.yaml'이라는 이름의 파일을 찾을 수 있습니다. 이 파일에는 Casdoor를 쿠버네티스에 배포하기 위한 예제 설정이 포함되어 있으며, 배포 및 서비스가 포함되어 있습니다.

배포를 시작하기 전에 conf/app.conf 파일을 수정하여 Casdoor가 데이터베이스에 성공적으로 연결할 수 있도록 하고, 데이터베이스 자체가 실행 중인지 확인해야 합니다. 또한, 쿠버네티스가 필요한 이미지를 끌어올 수 있는지 확인하세요.

Casdoor를 배포하려면 다음 명령을 실행하세요:

kubectl apply -f k8s.yaml

kubectl get pods 명령을 실행하여 배포 상태를 확인할 수 있습니다.

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

이 파일은 단지 예제일 뿐임을 유의하세요. 다른 네임스페이스, 서비스 유형 또는 구성 파일을 마운트하기 위한 ConfigMap을 사용하는 등 요구 사항에 따라 다양한 수정을 할 수 있습니다. ConfigMap을 사용하는 것은 프로덕션 환경에서 구성 파일을 마운트하기 위한 쿠버네티스에서 권장하는 접근 방식입니다.

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.