NetScaler を使用した Kubernetes の認証および認可ポリシー

最終公開日 : Oct 02, 2026
認証および認可ポリシーは、アプリケーションまたはAPIサーバーによってホストされるリソースへのアクセス制限を適用するために使用されます。認証ポリシーを使用してIDを検証できますが、認可ポリシーは、指定されたリクエストがリソースにアクセスするために必要な権限を持っているかどうかを検証するために使用されます。
NetScaler は、NetScaler Ingress Controller とともに使用して NetScaler 上で認証ポリシーを定義できる、Auth CRD と呼ばれる Kubernetes の CustomResourceDefinition (CRD) を提供します。
Related information
CRD

Auth CRD の定義

Auth CRD は、NetScaler Ingress Controller の GitHub リポジトリの auth-crd.yaml で入手できます。Auth CRD は、NetScaler 上で認証ポリシーを定義するために必要なさまざまなオプションの 属性 を提供します。

Auth CRD の属性

Auth CRD は、認証ポリシーを定義するために使用する次の属性を提供します。
  • servicenames
  • authentication_mechanism
  • authentication_providers
  • authentication_policies
  • authorization_policies

サービス名

認証および認可ポリシーを適用する必要があるサービスの名前。

認証メカニズム

以下の認証メカニズムがサポートされています。
  • リクエストヘッダーの使用:リクエストヘッダーを使用したユーザー認証を有効にします。このメカニズムは、資格情報またはAPIキーがヘッダー（通常はAuthorizationヘッダー）で渡される場合に使用できます。たとえば、基本認証、ダイジェスト認証、ベアラー認証、またはAPIキーにリクエストヘッダーを使用した認証を使用できます。
  • フォームの使用: このメカニズムは、OpenID Connectの依拠当事者構成やSAMLのサービスプロバイダー構成を含む、ユーザー認証またはWeb認証で使用できます。
認証メカニズムが指定されていない場合、デフォルトはリクエストヘッダーを使用した認証です。
以下は、フォームベース認証の属性です。
属性 説明
authentication_host ADC認証サービスのためにユーザーがリダイレクトされる完全修飾ドメイン名 (FQDN) を指定します。このFQDNは一意であり、Ingress/サービスタイプLoadBalancerを持つNetScalerのフロントエンドIPアドレス、またはListener CRDのVIPアドレスに解決される必要があります。
authentication_host_cert authentication_hostで使用するSSL証明書の名前を指定します。この証明書は、フォームを使用して認証を実行する際に必須です。
ingress_name フォームを使用した認証が適用されるIngress名を指定します。
ingressclass 指定されたIngressクラスに関連付けられたIngressコントローラーのみがリソースを処理するように、Ingressクラスを指定します。そうしないと、クラスター内のすべてのコントローラーがこのリソースを処理します。
lb_service_name フォームを使用した認証が適用されるLoadBalancerタイプのサービス名を指定します。
listener_name フォームを使用した認証が適用されるListener CRDの名前。
vip フォームを使用した認証が適用されるIngressのフロントエンドIPアドレスを指定します。この属性は、Ingressで提供されるfrontend-ipアドレスを参照します。同じフロントエンドIPを使用するIngressリソースが複数ある場合は、VIPを使用することをお勧めします。
注:
  • フォームを使用する場合、すべての種類のトラフィックに対して認証を有効にできます。現在、きめ細かな認証はサポートされていません。
  • フォームベース認証を適用する必要があるリソースに応じて、ingress_name、lb_service_name、listener_name、またはvipのいずれかの属性を使用してリソースを指定できます。

認証プロバイダー

プロバイダーは、認証メカニズムに必要な認証メカニズムとパラメーターを定義します。

基本認証

HTTP基本認証スキームでローカル認証が使用されることを指定します。基本認証を使用するには、イングレスNetScalerでユーザーアカウントを作成する必要があります。
注:
ローカル認証のユーザーは、NetScaler VPXまたはNetScaler MPXで作成する必要があります。CLIを使用してNetScalerでローカル認証のユーザーを作成するには、次のコマンドを実行します: add aaa user <username> -password <password>。GUIを使用してNetScalerでローカル認証のユーザーを作成する方法については、ローカルユーザーの構成を参照してください。

OAuth認証

OAuth認証メカニズムでは、oAuth2を使用してクライアントを認証し、アクセストークンを発行するために外部のIDプロバイダーを必要とします。クライアントがアクセストークンをアクセス資格情報としてNetScalerに提示すると、NetScalerは設定された値を使用してトークンを検証します。トークンの検証が成功した場合、NetScalerはクライアントにアクセスを許可します。
OAuth認証属性
OAuth認証の属性は次のとおりです。
属性 説明
Issuer 認証のためにトークンを受け入れる必要があるサーバーのID（通常はURL）。
jwks_uri JWT（JSON Web Token）検証のためのJWK（JSON Web Key）を含むエンドポイントのURL。
audience トークンが適用されるサービスまたはアプリケーションのID。
token_in_hdr トークンが存在するカスタムヘッダー名。デフォルト値はAuthorizationヘッダーです。
注: 複数のヘッダーを指定できます。
token_in_param トークンが存在するクエリパラメータ。
signature_algorithms 許可される署名アルゴリズムのリストを指定します。デフォルトでは、HS256、RS256、およびRS512アルゴリズムが許可されています。
introspect_url 認証サーバー (IdP) のイントロスペクションエンドポイントのURL。提示されたアクセストークンが不透明なトークンである場合、トークン検証のためにイントロスペクションが使用されます。
client_credentials 認証サーバーで認証するために必要なクライアントIDとクライアントシークレットを含むKubernetesシークレットオブジェクトの名前。
claims_to_save 保存するクレームのリスト。クレームは認可ポリシーの作成に使用されます。
OpenID Connect (OIDC) は、OAuth 2.0 プロトコル上に構築されたシンプルなIDレイヤーです。OIDC を使用すると、クライアントは認可サーバーによって実行された認証に基づいてエンドユーザーのIDを検証したり、エンドユーザーに関する基本的なプロファイル情報を取得したりできます。OAuth 属性に加えて、OIDC を構成するために次の属性を使用できます。
属性 説明
metadata_url OAUTHまたはOIDCプロバイダーのメタデータを取得するために使用されるURLを指定します。
user_field トークンからユーザー名を抽出する属性を指定します。デフォルトでは、NetScaler はユーザー ID のためにメール属性を調べます。
default_group 認証が成功した場合にリクエストに割り当てられるグループを指定します。このグループは、トークンから抽出されたグループに追加されます。
grant_type トークンエンドポイントへのフローのタイプを指定します。デフォルト値は CODE です。
pkce Proof Key for Code Exchange (PKCE) を有効にするかどうかを指定します。デフォルト値は ENABLED です。
token_ep_auth_method トークンエンドポイントで使用する認証方法を指定します。デフォルト値は client_secret_post です。

SAML認証

Security Assertion Markup Language (SAML) は、製品や組織間でユーザー認証を可能にするXMLベースのオープン標準です。SAML認証メカニズムでは、クライアントを認証するために外部のIDプロバイダーが必要です。SAMLは、クライアントIDをIDプロバイダーからNetScalerに転送することで機能します。クライアントIDの検証が成功すると、NetScalerはクライアントにアクセスを許可します。
SAML認証の属性は以下のとおりです。
属性 説明
metadata_url SAMLメタデータを取得するために使用されるURLを指定します。注: これは必須です。
metadata_refresh_interval 指定されたメタデータURLからメタデータをフェッチする間隔を分単位で指定します。デフォルト値は36000です。
signing_cert サービスプロバイダー (SP) からIDプロバイダー (IdP) へのリクエストに署名するためのSSL証明書を指定します。このパラメーターは、事前設定されている場合は文字列、またはKubernetes TLSタイプのシークレットである場合があります。
audience トークンが適用されるサービスまたはアプリケーションのIDを指定します。
issuer_name SPからIdPに送信されるリクエストで使用され、NetScalerを識別するための名前を指定します。
binding SAMLメッセージの転送メカニズムを指定します。デフォルト値は POST です。
artifact_resolution_service_url IdP上のアーティファクト解決サービスのURLを指定します。
logout_binding SAMLログアウトのトランスポートメカニズムを指定します。デフォルト値はPOSTです。
reject_unsigned_assertion 署名されていないSAMLアサーションを拒否します。この値がONの場合、署名のないアサーションを拒否します。デフォルト値はONです。
user_field SAMLアサーションで指定されたSAMLユーザーIDを指定します
default_authentication_group 抽出されたグループに加えて、認証が成功したときに選択されるデフォルトグループを指定します。
skew_time 受信SAMLアサーションで許可されるクロックスキュー時間（分単位）を指定します。デフォルト値は5です。
attributes_to_save NetScaler上のセッションのためにキーと値のペアとして抽出および保存する必要がある、コンマで区切られた属性名のリストを指定します。

LDAP認証

LDAP (Lightweight Directory Access Protocol) は、インターネットプロトコル (IP) ネットワーク上で分散ディレクトリ情報サービスにアクセスし、維持するための、オープンでベンダーに依存しない業界標準のアプリケーションプロトコルです。LDAPの一般的な用途は、ユーザー名とパスワードを保存するための一元的な場所を提供することです。LDAPを使用すると、多くの異なるアプリケーションやサービスがLDAPサーバーに接続してユーザーを検証できます。
注記:
LDAP認証は、リクエストヘッダーを使用する認証メカニズムとフォームを使用する認証メカニズムの両方でサポートされています。
以下は、LDAP認証の属性です。
属性 説明
server_ip LDAPサーバーに割り当てられたIPアドレスを指定します。
server_name FQDNとしてのLDAPサーバー名を指定します。
server_port LDAPサーバーが接続を受け入れるポートを指定します。デフォルト値は389です。
base LDAP検索を開始するベースノードを指定します。LDAPサーバーがローカルで実行されている場合、ベースのデフォルト値はdc=netscaler、dc=comです。
server_login_credentials LDAPサーバーにログインするための資格情報を提供するKubernetesシークレットオブジェクトを指定します。シークレットデータにはユーザー名とパスワードが含まれている必要があります。
login_name 「LDAPログイン名」属性を指定します。NetScalerは、外部LDAPサーバーまたはActive Directoryを照会するためにLDAPログイン名を使用します。
security_type NetScalerとLDAPサーバー間の通信に使用されるセキュリティの種類を指定します。デフォルトはTLSです。
validate_server_cert LDAPサーバー証明書を検証します。デフォルト値はNOです。
hostname LDAPサーバーのホスト名を指定します。validate_server_certがONの場合、この値はLDAPからの証明書上のホスト名である必要があります。ホスト名が一致しないと、接続エラーが発生します。
sub_attribute_name LDAPグループのサブ属性名を指定します。この属性は、LDAPサーバーからのグループ抽出に使用されます。
group_attribute_name LDAPグループの属性名を指定します。この属性は、LDAPサーバーでのグループ抽出に使用されます。
search_filter デフォルトのLDAPユーザー検索文字列と組み合わせて検索値を形成する文字列を指定します。たとえば、検索フィルター「"vpnallowed=true"」がLDAPログイン名「"samaccount"」とユーザーが指定したユーザー名「"bob"」と組み合わされた場合、結果はLDAP検索文字列「"(&(vpnallowed=true)(samaccount=bob))"」になります。検索文字列は二重引用符で二重に囲んでください。
auth_timeout NetScalerがサーバーからの応答を待つ秒数を指定します。デフォルト値は3です。
password_change パスワード変更要求を許可します。デフォルト値はDISABLEDです。
attributes_to_save LDAPサーバーから取得し、NetScaler上のセッションのキーと値のペアとして保存する必要がある、コンマで区切られた属性名のリスト。

認証ポリシー

authentication_policiesを使用すると、認証メカニズムを適用するためのトラフィック選択基準を定義し、選択したトラフィックに使用するプロバイダーを指定できます。
認証ポリシーは、認証ルールを指定できる2つの形式をサポートしています。
  • リソース形式
  • 式形式
リソース形式のポリシーの属性は次のとおりです。
属性 説明
path 特定のAPIエンドポイントを参照するURLパスプレフィックスの配列。例: /api/v1/products/。
method HTTPメソッドの配列。許可される値はGET、PUT、POST、またはDELETEです。受信リクエストURIが、いずれかのパスおよびリストされたいずれかのメソッドと一致する場合にトラフィックが選択されます。メソッドが指定されていない場合、パスのみがトラフィック選択基準として使用されます。
provider 使用する必要がある認証メカニズムを指定します。認証メカニズムが提供されていない場合、認証は実行されません。
以下の属性は、式形式の認証ポリシー用です。
属性 説明
expression 認証に基づいて評価されるNetScaler式を指定します。
provider 使用する必要がある認証メカニズムを指定します。認証メカニズムが提供されていない場合、認証は実行されません。
注:
特定のエンドポイントの認証をスキップしたい場合は、provider 属性を空のリストとして設定したポリシーを作成します。そうしないと、リクエストは拒否されます。

承認ポリシー

承認ポリシーを使用すると、選択したトラフィックに承認要件を適用するためのトラフィック選択基準を定義できます。
承認ポリシーは、承認ルールを指定できる2つの形式をサポートしています。
  • リソース形式
  • 式形式
以下は、リソース形式の承認ポリシーの属性です。
属性 説明
path 特定のAPIエンドポイントを参照するURLパスプレフィックスの配列です。例えば、/api/v1/products/。
method HTTPメソッドの配列です。許可される値はGET、PUT、POST、またはDELETEです。
claims 特定のAPIエンドポイントにアクセスするために必要なクレームを指定します。nameはクレーム名を示し、valuesは必要な権限を示します。複数のクレームを持つことができます。空のリストが指定された場合、承認は不要であることを意味します。
注: 承認に使用する必要があるクレームは、認証の一部として保存する必要があります。
以下は、式形式の承認ポリシーの属性です。
属性 説明
expression 認可のために評価される式を指定します。
注意:
NetScalerは、APIトラフィックに対して認証ポリシーと認可ポリシーの両方を必要とします。したがって、認証ポリシーとともに認可ポリシーを設定する必要があります。認可チェックがない場合でも、空のクレームを持つ認可ポリシーを作成する必要があります。そうしないと、リクエストは403エラーで拒否されます。
注意:
受信リクエストがポリシー（パス、メソッド、クレーム）に一致する場合、認可は成功します。一致するまで、すべてのポリシーが試行されます。特定のエンドポイントの認可を選択的にバイパスする必要がある場合は、明示的なポリシーを作成する必要があります。

Auth CRD のデプロイ

Auth CRD をデプロイするには、以下を実行します。
  1. CRD (auth-crd.yaml) をダウンロードします。
  2. 次のコマンドを使用して Auth CRD をデプロイします。
    kubectl create -f auth-crd.yaml
    例:
    root@master:~# kubectl create -f auth-crd.yaml

    customresourcedefinition.apiextensions.k8s.io/authpolicies.citrix.com created

認証ポリシーと認可ポリシーの記述方法

KubernetesクラスターにNetScalerが提供するCRDをデプロイした後、.yamlファイルで認証ポリシー構成を定義できます。.yamlファイルでは、kindフィールドでauthpolicyを使用し、specセクションでポリシー構成の要件に基づいてAuth CRD属性を追加します。
.yamlファイルをデプロイすると、NetScaler Ingress ControllerはNetScalerに認証ポリシー構成を適用します。

ローカル認証プロバイダー

以下は、local-auth-provider タイプの認証および認可ポリシー定義のサンプルです (local_auth.yaml)。
  apiVersion: citrix.com/v1beta1
  kind: authpolicy
  metadata:
    name: authexample
  spec:
      servicenames:
      - frontend

      authentication_providers:
          - name: "local-auth-provider"
            basic_local_db:
                use_local_auth: 'YES'

      authentication_policies:
          - resource:
              path:
                - '/orders/'
                - '/shipping/'
              method: [GET, POST]
            provider: ["local-auth-provider"]

          # skip authentication for this
          - resource:
              path:
                - '/products/'
              method: [GET]
            provider: []

      authorization_policies:
          # skip authorization
          - resource:
              path: []
              method: []
              claims: []
サンプルのポリシー定義は以下を実行します。
  • NetScaler は、以下のリクエストに対してローカル認証を実行します。
    • orders および shipping エンドポイントに対する GET または POST 操作。
  • NetScaler は、products エンドポイントに対する GET 操作の認証を実行しません。
  • NetScaler は、いかなる認可権限も適用しません。
注:
ローカル認証のユーザーは、NetScaler VPX または NetScaler MPX 上で作成する必要があります。CLI を使用して NetScaler 上でローカル認証のユーザーを作成するには、次のコマンドを実行します: add aaa user <username> -password <password>。GUI を使用して NetScaler 上でローカル認証のユーザーを作成する方法については、「ローカルユーザーの構成」を参照してください。

oAuth JWT 検証

以下は、oAuth JWT 検証の認証および認可ポリシー定義のサンプルです (oauth_jwt_auth.yaml)。
apiVersion: citrix.com/v1beta1
kind: authpolicy
metadata:
  name: authexample
spec:
    servicenames:
    - frontend

    authentication_providers:
      - name: "jwt-auth-provider"
        oauth:
          issuer: "https://sts.windows.net/tenant1/"
          jwks_uri: "https://login.microsoftonline.com/tenant1/discovery/v2.0/keys"
          audience : ["https://api.service.net"]
          claims_to_save : ["scope"]

    authentication_policies:
        - resource:
            path:
              - '/orders/'
              - '/shipping/'
            method: [GET, POST]
          provider: ["jwt-auth-provider"]

        # skip authentication for this
        - resource:
            path:
              - '/products/'
            method: [GET]
          provider: []

    authorization_policies:
        - resource:
            path:
              - '/orders/'
              - '/shipping/'
            method: [POST]
            claims:
              - name: "scope"
                values: ["read", "write"]
        - resource:
            path:
              - '/orders/'
            method: [GET]
            claims:
              - name: "scope"
                values: ["read"]
        # skip authorization, no claims required
        - resource:
            path:
              - '/shipping/'
            method: [GET]
            claims: []
サンプルのポリシー定義は以下を実行します。
  • NetScaler は、以下のリクエストに対して JWT 検証を実行します。
    • orders および shipping エンドポイントに対する GET または POST 操作。
  • NetScaler は、products エンドポイントに対する GET 操作の認証をスキップします。
  • NetScaler は、orders および shipping エンドポイントでの POST 操作に対して、read および write 権限を持つスコープクレームを必要とします。
  • NetScaler は、orders エンドポイントでの GET 操作に対して、読み取り権限を持つスコープクレームを必要とします。
  • NetScaler は、shipping エンドポイントでの GET 操作に対して、いかなる権限も必要としません。
OAuth の場合、トークンがカスタムヘッダーに存在する場合、token_in_hdr 属性を使用して次のように指定できます。
oauth:
  issuer: "https://sts.windows.net/tenant1/"
  jwks_uri: "https://login.microsoftonline.com/tenant1/discovery/v2.0/keys"
  audience : ["https://vault.azure.net"]
  token_in_hdr : [“custom-hdr1”]
同様に、トークンがクエリパラメータに存在する場合、token_in_param 属性を使用して次のように指定できます。
oauth:
  issuer: "https://sts.windows.net/tenant1/"
  jwks_uri: "https://login.microsoftonline.com/tenant1/discovery/v2.0keys"
  audience : ["https://vault.azure.net"]
  token_in_param : [“query-param1”]

OAuth イントロスペクション

以下は、OAuth JWT 検証の認証および認可ポリシー定義のサンプルです。(oauth_intro_auth.yaml)
  apiVersion: citrix.com/v1beta1
  kind: authpolicy
  metadata:
    name: authexample
  spec:
      servicenames:
      - frontend

      authentication_providers:
          - name: "introspect-provider"
            oauth:
              issuer: "ns-idp"
              jwks_uri: "https://idp.aaa/oauth/idp/certs"
              audience : ["https://api.service.net"]
              client_credentials: "oauthsecret"
              introspect_url: https://idp.aaa/oauth/idp/introspect
              claims_to_save : ["scope"]

      authentication_policies:
          - resource:
              path: []
              method: []
            provider: ["introspect-provider"]

      authorization_policies:
          - resource:
              path: []
              method: [POST]
              claims:
              - name: "scope"
                values: ["read", "write"]
          - resource:
              path: []
              method: [GET]
              claims:
              - name: "scope"
                values: ["read"]
サンプルポリシー定義は以下を実行します。
  • NetScaler は、すべてのリクエストに対して、プロバイダー introspect-provider で指定された OAuth イントロスペクションを実行します。
  • NetScaler は、すべての POST リクエストに対して、read および write 権限を持つスコープクレームを必要とします。
  • NetScaler は、すべての GET リクエストに対して、読み取り権限を持つスコープクレームを必要とします。

イントロスペクション用のクライアント資格情報を含むシークレットオブジェクトの作成

OAuth イントロスペクションを設定するには、Kubernetes シークレットオブジェクトが必要です。 以下の例に示すように、シークレットオブジェクトを作成できます。
apiVersion: v1
kind: Secret
metadata:
  name: oauthsecret
type: Opaque
stringData:
 client_id: "nsintro"
 client_secret: "nssintro"
注:
不透明なシークレットオブジェクトのキーは client_id と client_secret である必要があります。ユーザーは必要に応じてそれらの値を設定できます。

フォームを使用したSAML認証

以下は、フォームを使用したSAML認証の例です。この例では、authhost-tls-cert-secretとsaml-tls-cert-secretは、証明書とキーを参照するKubernetes TLSシークレットです。
注:
certkey.certとcertkey.keyがそれぞれ認証ホストの証明書とキーである場合、authhost-tls-cert-secretは次のコマンドを使用して作成できます。
kubectl create secret tls authhost-tls-cert-secret --key="certkey.key" --cert="certkey.cert
同様に、このコマンドを使用して、必要な証明書とキーでsaml-tls-cert-secretを形成できます。

apiVersion: citrix.com/v1beta1
kind: authpolicy
metadata:
  name: samlexample
spec:
    servicenames:
    - frontend

    authentication_mechanism:
      using_forms:
        authentication_host: "fqdn_authenticaton_host"
        authentication_host_cert:
          tls_secret: authhost-tls-cert-secret
        listener_name: “example-listener”

    authentication_providers:
        - name: "saml-auth-provider"
          saml:
              metadata_url: "https://idp.aaa/metadata/samlidp/aaa"
              signing_cert:
                  tls_secret: saml-tls-cert-secret

    authentication_policies:

        - resource:
            path: []
            method: []
          provider: ["saml-auth-provider"]

    authorization_policies:

        - resource:
            path: []
            method: []
            claims: []
サンプルポリシー定義は以下を実行します。
  • NetScalerは、すべてのリクエストに対して、プロバイダーsaml-auth-providerで指定されたSAML認証を実行します。 注: フォームメカニズムでは、きめ細かな認証はサポートされていません。
  • NetScalerは、すべてのPOSTリクエストに対して、admin権限を持つグループクレームを要求します。
  • NetScalerは、GETリクエストに対して特定の権限を要求しません。

フォームを使用したOpenID Connect認証

以下は、外部IDプロバイダーのユーザーを認証するために、NetScalerをリレーイングパーティ（RP）ロールで構成するOpenID Connect認証を作成する例です。OpenID Connectの手順をトリガーするには、authentication_mechanismをusing_formsに設定する必要があります。
apiVersion: citrix.com/v1beta1
kind: authpolicy
metadata:
  name: authoidc
spec:
    servicenames:
    - frontend
    authentication_mechanism:
        using_forms:
            authentication_host: "10.221.35.213"
            authentication_host_cert:
                 tls_secret: "oidc-tls-secret"
            ingress_name:  “example-ingress”

    authentication_providers:

        - name: "oidc-provider"
          oauth:
            audience : ["https://app1.citrix.com"]
            client_credentials: "oidcsecret"
            metadata_url: "https://10.221.35.214/oauth/idp/.well-known/openid-configuration"
            default_group: "groupA"
            user_field: "sub"
            pkce: "ENABLED"
            token_ep_auth_method: "client_secret_post"

    authentication_policies:

        - resource:
            path: []
            method: []
          provider: ["oidc-provider"]

    authorization_policies:

        #default - no authorization requirements
        - resource:
            path: []
            method: []
            claims: []
サンプルポリシー定義は以下を実行します。
  • NetScalerは、すべてのリクエストに対して、プロバイダーoidc-providerで指定されたOIDC認証（リレーイングパーティ）を実行します。
    注: フォームメカニズムでは、きめ細かな認証はサポートされていません。
  • NetScalerは、いかなる承認権限も要求しません。

リクエストヘッダーを使用したLDAP認証

以下は、リクエストヘッダーを使用したLDAP認証の例です。
この例では、ldapcredential はLDAPサーバーの資格情報を参照するKubernetesシークレットです。LDAPサーバーの資格情報の作成方法については、ldap_secret.yaml ファイルを参照してください。

apiVersion: citrix.com/v1beta1
kind: authpolicy
metadata:
  name: ldapexample
spec:
    servicenames:
    - frontend

    authentication_providers:
        - name: "ldap-auth-provider"
          ldap:
              server_ip: "192.2.156.160"
              base: 'dc=aaa,dc=local'
              login_name: accountname
              sub_attribute_name: CN
              server_login_credentials: ldapcredential

        - name: "local-auth-provider"
          basic_local_db:
              use_local_auth: 'YES'

    authentication_policies:

        - resource:
            path: []
            method: []
          provider: ["ldap-auth-provider"]


    authorization_policies:

        - resource:
            path: []
            method: []
            claims: []
注: リクエストヘッダーベースの認証メカニズムでは、トラフィックに基づいたきめ細かな認証がサポートされています。

フォームを使用したLDAP認証

この例では、authhost-tls-cert-secret は証明書とキーを参照するKubernetes TLSシークレットです。
certkey.cert と certkey.key がそれぞれ認証ホストの証明書とキーである場合、authhost-tls-cert-secret は次の コマンドを使用して形成できます。
kubectl create secret tls authhost-tls-cert-secret --key="certkey.key" --cert="certkey.cert
この例では、ldapcredential はLDAPサーバーの資格情報を参照するKubernetesシークレットです。LDAPサーバーの資格情報の作成方法については、ldap_secret.yaml ファイルを参照してください。
apiVersion: citrix.com/v1beta1
kind: authpolicy
metadata:
  name: ldapexample
spec:
    servicenames:
    - frontend

    authentication_mechanism:
      using_forms:
        authentication_host: "fqdn_authenticaton_host"
        authentication_host_cert:
          tls_secret: authhost-tls-cert-secret
        vip: "192.2.156.156"

    authentication_providers:
        - name: "ldap-auth-provider"
          ldap:
              server_ip: "192.2.156.160"
              base: 'dc=aaa,dc=local'
              login_name: accountname
              sub_attribute_name: CN
              server_login_credentials: ldapcredential

    authentication_policies:

        - resource:
            path: []
            method: []
          provider: ["ldap-auth-provider"]

    authorization_policies:

        - resource:
            path: []
            method: []
            claims: []
サンプルポリシー定義は以下を実行します。
  • NetScalerは、すべてのトラフィック（すべてのリクエスト）に対してLDAP認証を実行します。
  • NetScalerは、いかなる承認権限も適用しません。
以下は、LDAP_secret.yaml の例です。
apiVersion: v1
kind: Secret
metadata:
  name: ldapcredential
type: Opaque
stringData:
  username: 'ldap_server_username'
  password: 'ldap_server_password'

Auth CRDでのNetScaler式サポートの例

この例では、認証および承認ポリシーとともにNetScaler式を指定する方法を示します。
  apiVersion: citrix.com/v1beta1
  kind: authpolicy
  metadata:
    name: authexample
  spec:
      servicenames:
      - frontend

      authentication_mechanism:
        using_request_header: 'ON'

      authentication_providers:
          - name: "ldap-auth-provider"
            ldap:
                server_ip: "192.2.156.160"
                base: 'dc=aaa,dc=local'
                login_name: accountname
                sub_attribute_name: CN
                server_login_credentials: ldapcredential
                # "memberof" attribute details are extracted from LDAP server.
                attributes_to_save: memberof

      authentication_policies:
          # Perform LDAP authentication for the host hotdrink.beverages.com
          - expression: 'HTTP.REQ.HOSTNAME.SET_TEXT_MODE(IGNORECASE).EQ("hotdrink.beverages.com")'
            provider: ["ldap-auth-provider"]


      authorization_policies:
          # ALLOW the session only if the authenticated user is associated with attribute "memberof" having value "grp4"
          - expression: 'aaa.user.attribute("memberof").contains("grp4")'