Zero TrustとIdentity-Aware Proxy — BeyondCorpモデルを自分で構築する

                        +----------------------------+
                        |   Identity Provider (IdP)  |
                        |   Keycloak / OIDC          |
                        +-------------+--------------+
                                      | (2) OIDC認証
                                      | Authorization Code + PKCE
+----------+   (1) HTTPS   +----------+-----------+   (4) ヘッダー注入  +-------------+
| ユーザーの +-------------->+  Identity-Aware Proxy +------------------->+  社内アプリ  |
| ブラウザ   |               |  (oauth2-proxyなど)   |   X-Forwarded-*    |  (adminなど) |
+----------+               +----------+-----------+                    +-------------+
                                      |
                                      | (3) ポリシー評価
                                      |  - ユーザーのグループ/ロール
                                      |  - デバイスの状態
                                      |  - 位置/時間コンテキスト
                                      v
                           +----------------------+
                           |  Policy / Device DB  |
                           +----------------------+

# Keycloak admin CLIにログイン
kcadm.sh config credentials \
  --server https://keycloak.example.com \
  --realm master \
  --user admin

# oauth2-proxy用クライアントを作成
kcadm.sh create clients -r internal -f - <<'EOF'
{
  "clientId": "oauth2-proxy",
  "protocol": "openid-connect",
  "publicClient": false,
  "standardFlowEnabled": true,
  "directAccessGrantsEnabled": false,
  "serviceAccountsEnabled": false,
  "redirectUris": ["https://admin.example.com/oauth2/callback"],
  "attributes": {
    "pkce.code.challenge.method": "S256",
    "post.logout.redirect.uris": "https://admin.example.com"
  }
}
EOF

# groupsクレームをIDトークンに含めるマッパー
CLIENT_UUID=$(kcadm.sh get clients -r internal -q clientId=oauth2-proxy --fields id --format csv --noquotes)

kcadm.sh create clients/$CLIENT_UUID/protocol-mappers/models -r internal -f - <<'EOF'
{
  "name": "groups",
  "protocol": "openid-connect",
  "protocolMapper": "oidc-group-membership-mapper",
  "config": {
    "claim.name": "groups",
    "full.path": "false",
    "id.token.claim": "true",
    "access.token.claim": "true",
    "userinfo.token.claim": "true"
  }
}
EOF

apiVersion: v1
kind: Secret
metadata:
  name: oauth2-proxy-secrets
  namespace: iap
type: Opaque
stringData:
  client-secret: 'REPLACE_WITH_KEYCLOAK_CLIENT_SECRET'
  # python -c 'import secrets; print(secrets.token_urlsafe(32))'
  cookie-secret: 'REPLACE_WITH_32_BYTE_RANDOM'
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: oauth2-proxy
  namespace: iap
  labels:
    app: oauth2-proxy
spec:
  replicas: 2
  selector:
    matchLabels:
      app: oauth2-proxy
  template:
    metadata:
      labels:
        app: oauth2-proxy
    spec:
      containers:
        - name: oauth2-proxy
          image: quay.io/oauth2-proxy/oauth2-proxy:v7.8.1
          args:
            - --provider=keycloak-oidc
            - --client-id=oauth2-proxy
            - --oidc-issuer-url=https://keycloak.example.com/realms/internal
            - --code-challenge-method=S256
            - --redirect-url=https://admin.example.com/oauth2/callback
            - --email-domain=example.com
            - --allowed-group=platform-admins
            - --scope=openid email profile groups
            - --cookie-secure=true
            - --cookie-samesite=lax
            - --cookie-refresh=4m
            - --cookie-expire=8h
            - --session-store-type=redis
            - --redis-connection-url=redis://redis.iap.svc.cluster.local:6379
            - --set-xauthrequest=true
            - --set-authorization-header=true
            - --pass-access-token=false
            - --skip-provider-button=true
            - --reverse-proxy=true
            - --http-address=0.0.0.0:4180
            - --metrics-address=0.0.0.0:44180
          env:
            - name: OAUTH2_PROXY_CLIENT_SECRET
              valueFrom:
                secretKeyRef:
                  name: oauth2-proxy-secrets
                  key: client-secret
            - name: OAUTH2_PROXY_COOKIE_SECRET
              valueFrom:
                secretKeyRef:
                  name: oauth2-proxy-secrets
                  key: cookie-secret
          ports:
            - containerPort: 4180
              name: http
            - containerPort: 44180
              name: metrics
          readinessProbe:
            httpGet:
              path: /ping
              port: 4180
          resources:
            requests:
              cpu: 50m
              memory: 64Mi
            limits:
              memory: 256Mi
---
apiVersion: v1
kind: Service
metadata:
  name: oauth2-proxy
  namespace: iap
spec:
  selector:
    app: oauth2-proxy
  ports:
    - name: http
      port: 4180
      targetPort: 4180

server {
    listen 443 ssl;
    server_name admin.example.com;

    ssl_certificate     /etc/nginx/tls/tls.crt;
    ssl_certificate_key /etc/nginx/tls/tls.key;

    # 認証チェックのサブリクエスト — oauth2-proxyの /oauth2/auth は
    # 認証済みなら202、そうでなければ401を返す
    location = /oauth2/auth {
        internal;
        proxy_pass http://oauth2-proxy.iap.svc.cluster.local:4180;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
        # ボディの転送は不要
        proxy_pass_request_body off;
        proxy_set_header Content-Length "";
    }

    # ログインフロー(リダイレクト、コールバック、ログアウト)
    location /oauth2/ {
        proxy_pass http://oauth2-proxy.iap.svc.cluster.local:4180;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    location / {
        auth_request /oauth2/auth;
        # 401ならログインへリダイレクト
        error_page 401 = /oauth2/start?rd=$scheme://$host$request_uri;

        # authサブリクエストのレスポンスヘッダーから身元情報を取り出し
        # アップストリームへ注入する
        auth_request_set $user   $upstream_http_x_auth_request_user;
        auth_request_set $email  $upstream_http_x_auth_request_email;
        auth_request_set $groups $upstream_http_x_auth_request_groups;
        proxy_set_header X-Forwarded-User   $user;
        proxy_set_header X-Forwarded-Email  $email;
        proxy_set_header X-Forwarded-Groups $groups;

        # ユーザーが偽造した身元ヘッダーが通らないよう
        # 上のproxy_set_headerが常に上書きする構造を維持する

        proxy_pass http://admin-dashboard.apps.svc.cluster.local:8080;
    }
}

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: admin-dashboard
  namespace: apps
  annotations:
    nginx.ingress.kubernetes.io/auth-url: 'https://admin.example.com/oauth2/auth'
    nginx.ingress.kubernetes.io/auth-signin: 'https://admin.example.com/oauth2/start?rd=$scheme://$host$request_uri'
    nginx.ingress.kubernetes.io/auth-response-headers: 'X-Auth-Request-User, X-Auth-Request-Email, X-Auth-Request-Groups'
spec:
  ingressClassName: nginx
  rules:
    - host: admin.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: admin-dashboard
                port:
                  number: 8080
  tls:
    - hosts:
        - admin.example.com
      secretName: admin-dashboard-tls

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: admin-dashboard-only-from-ingress
  namespace: apps
spec:
  podSelector:
    matchLabels:
      app: admin-dashboard
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: ingress-nginx
      ports:
        - protocol: TCP
          port: 8080

server {
    listen 443 ssl;
    server_name payments-admin.example.com;

    ssl_client_certificate /etc/nginx/tls/device-ca.crt;
    ssl_verify_client on;

    location / {
        auth_request /oauth2/auth;
        # デバイス証明書の情報をアップストリームと監査ログへ渡す
        proxy_set_header X-Device-Cert-DN $ssl_client_s_dn;
        proxy_set_header X-Device-Cert-Verify $ssl_client_verify;
        proxy_pass http://payments-admin.apps.svc.cluster.local:8080;
    }
}

[Before] 全社員 --> VPN Gateway --> 社内ネットワーク全体 (wiki, CI, admin, DB, SSH ...)

[After]
  社員/委託先 --> IAP (HTTPS) --> wiki、CI、adminなどのWebアプリ        (トラフィックの大半)
  運用者     --> SSH/DB専用ソリューション(Boundary、Teleportなど)       (非HTTPプロトコル)
  レガシー    --> 残存VPN (段階的に縮小、対象サブネットを最小化)

# grafana.ini — IAPの背後でのヘッダーベース認証
[auth.proxy]
enabled = true
header_name = X-Forwarded-User
header_property = username
auto_sign_up = true
sync_ttl = 60
# プロキシのIPのみ信頼(偽造防止の最後の砦)
whitelist = 10.0.0.0/8

Phase 0  現状把握 (1か月)
         - 社内アプリのインベントリ、認証方式、機密度の分類
         - IdPの整備: グループ/ロール体系、MFA(可能ならパスキー)有効化

Phase 1  パイロット (1〜2か月)
         - 低リスクのアプリ2〜3個(wiki、ダッシュボード)をIAPの背後へ移行
         - ログインUX、セッションポリシー、障害モードの検証

Phase 2  拡大 (3〜6か月)
         - adminツール全体 + 新規アプリはデフォルトでIAP適用
         - デバイス証明書(mTLS)の配布、信頼レベルの導入
         - 非HTTPアクセス(SSH/DB)にTeleportなどを導入

Phase 3  VPN縮小 (6〜12か月)
         - VPNのアクセス対象をレガシーシステムに限定
         - コンテキストベースのポリシー(位置、時間、step-up)の高度化
         - ポリシーのコード化(IaC)と定期アクセスレビューの自動化

Phase 4  継続的改善
         - セッション異常検知、リスクベースの再認証
         - ワークロードidentity(SPIFFE)とユーザーidentityのポリシー統合