Citrix ADC ingress controller

Citrix ADCを使用したKubernetesの認証および承認ポリシー

認証ポリシーと承認ポリシーは、アプリケーションまたは API サーバーによってホストされるリソースへのアクセス制限を強制するために使用されます。認証ポリシーを使用して ID を確認できますが、承認ポリシーは、指定されたリクエストにリソースへのアクセスに必要な権限があるかどうかを検証するために使用されます。

Citrixでは、Auth CRDと呼ばれるKubernetes CustomResourceDefinition(CRD)を提供しています。このCRDは、Citrix Ingress Controller とともに使用して、イングレスCitrix ADCで認証ポリシーを定義できます。

Auth CRD 定義

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

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は一意である必要があり、入力/サービスタイプがLoadBalancerのCitrix ADC フロントエンドIPアドレス、またはリスナーCRDのVIPアドレスに解決される必要があります。
authentication_host_cert authentication_hostで使用する SSL 証明書の名前を指定します 。この証明書は、フォームを使用して認証を実行する際に必須です。
ingress_name フォームを使用した認証を適用できる Ingress 名を指定します。
lb_service_name フォームを使用した認証を適用できる LoadBalancer タイプのサービスの名前を指定します。
listener_name フォームを使用した認証を適用できるリスナー CRD の名前。
vip フォームを使用した認証を適用できる Ingress のフロントエンド IP アドレスを指定します。この属性は、Ingressで指定されたfrontend-ipアドレスを参照します。同じ frontend-ip を使用する Ingress リソースが複数ある場合は、vip を使用することをお勧めします。

注:

  • フォームの使用中は、すべての種類のトラフィックに対して認証を有効にできます。現在、きめ細かな認証はサポートされていません。

  • フォームベース認証を適用する必要があるリソースに応じて、ingress_namelb_service_namelistener_nameまたはvip属性のいずれかを使用してリソースを指定できます。

認証プロバイダー

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

ベーシック認証

HTTP Basic 認証方式でローカル認証を使用することを指定します。基本認証を使用するには、Ingress Citrix ADCでユーザーアカウントを作成する必要があります。

OAuth 認証

OAuth 認証メカニズムでは、外部 ID プロバイダーが OAuth2 を使用してクライアントを認証し、アクセストークンを発行する必要があります。クライアントがアクセストークンをアクセス資格情報としてCitrix ADCに提示すると、Citrix ADCは構成された値を使用してトークンを検証します。トークンの検証が成功すると、Citrix ADC はクライアントへのアクセスを許可します。

OAuth 認証属性

OAuth 認証の属性は次のとおりです。

属性 説明
Issuer 認証のためにトークンを受け入れる必要があるサーバーの ID (通常は URL)。
jwks_uri JWT (JSON Web トークン) 検証用の JWK (JSON Web キー) を含むエンドポイントの 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 ユーザー名の抽出元となるトークンの属性を指定します。デフォルトでは、Citrix ADC はユーザーIDの電子メール属性を調べます。
default_group 認証が成功した場合に要求に割り当てられるグループを指定します。このグループは、トークンから抽出されたグループに追加されます。
grant_type トークンエンドポイントへのフローのタイプを指定します。デフォルト値はCODEです。
pkce コード交換 (PKCE) の証明キーを有効にするかどうかを指定します。デフォルト値はENABLEDです。
token_ep_auth_method トークンエンドポイントで使用する認証方法を指定します。デフォルト値はclient_secret_postです。

SAML認証

セキュリティアサーションマークアップ言語 (SAML) は XML ベースのオープンスタンダードで、製品や組織全体でユーザーを認証できます。SAML 認証メカニズムでは、外部 ID プロバイダーがクライアントを認証する必要があります。SAMLは、クライアントIDをIDプロバイダーからCitrix ADCに転送することで機能します。クライアントIDの検証に成功すると、Citrix ADCはクライアントへのアクセスを許可します。

SAML 認証の属性は次のとおりです。

属性 説明
metadata_url SAML メタデータの取得に使用される URL を指定します。
metadata_refresh_interval 指定したメタデータ URL からメタデータを取得する間隔を分単位で指定します。
signing_cert サービスプロバイダー (SP) から ID プロバイダー (IdP) へのリクエストに署名するための SSL 証明書を指定します。
audience トークンを適用できるサービスまたはアプリケーションの ID を指定します。
issuer_name Citrix ADC を識別するために SP から IdP に送信される要求で使用される名前を指定します。
binding SAML メッセージの転送メカニズムを指定します。デフォルト値はPOSTです。
artifact_resolution_service_url IdP 上の Artifact 解決サービスの URL を指定します。
logout_binding SAML ログアウトの転送メカニズムを指定します。デフォルト値はPOSTです。
reject_unsigned_assertion 署名されていない SAML アサーションを拒否します。この値がONの場合、署名のないアサーションは拒否されます。
user_field SAML アサーションで指定された SAML ユーザ ID を指定します。
default_authentication_group 抽出されたグループに加えて、認証が成功した場合に選択されるデフォルトグループを指定します。
skewtime 受信 SAML アサーションで許容されるクロックスキュー時間を分単位で指定します。
attributes_to_save Citrix ADC上のセッションでキーと値のペアとして抽出して保存する必要がある、カンマで区切られた属性名のリストを指定します。

LDAP認証

LDAP (Lightweight Directory Access Protocol) は、インターネットプロトコル (IP) ネットワーク経由で分散ディレクトリインフォメーションサービスにアクセスして保守するための、ベンダーに依存しない、オープンで業界標準のアプリケーションプロトコルです。LDAP の一般的な用途は、ユーザー名とパスワードを一元的に保存する場所を提供することです。LDAP を使用すると、さまざまなアプリケーションやサービスが LDAP サーバに接続してユーザを検証できます。

注:

LDAP 認証は、リクエストヘッダーまたはフォームを使用する両方の認証メカニズムでサポートされます。

LDAP 認証の属性は次のとおりです。

属性 説明
server_ip LDAP サーバーに割り当てられている IP アドレスを指定します。
server_name LDAP サーバー名を FQDN として指定します。
server_port LDAP サーバーが接続を受け入れるポートを指定します。デフォルト値は 389 です。
base LDAP 検索を開始するベースノードを指定します。LDAP サーバーがローカルで実行されている場合、base のデフォルト値は dc=netscalerdc=comです。
server_login_credentials LDAP サーバーにログインするための認証情報を提供する Kubernetes シークレットオブジェクトを指定します。シークレットデータにはユーザー名とパスワードが必要です。
login_name LDAP ログイン名属性を指定します 。Citrix ADCは、LDAPログイン名を使用して外部のLDAPサーバーまたはActive Directoryを照会します。
security_type Citrix ADCとLDAPサーバー間の通信に使用されるセキュリティの種類を指定します。デフォルトは TLS です。
validate_server_cert LDAP サーバー証明書を検証します。デフォルト値はNOです。
hostname LDAP サーバのホスト名を指定します。validate_server_certONの場合、この値は LDAP からの証明書のホスト名である必要があります。ホスト名が一致しないと、接続に失敗します。
sub_attribute_name LDAP グループサブ属性名を指定します。この属性は、LDAP サーバからのグループの抽出に使用されます。
group_attribute_name LDAP グループ属性名を指定します。この属性は、LDAP サーバでのグループの抽出に使用されます。
search_filter デフォルトの LDAP ユーザ検索文字列と組み合わせて検索値を構成する文字列を指定します。たとえば、検索フィルタ「vpnallowed=true」が LDAP ログイン名「samaccount」と組み合わされ、ユーザ指定のユーザ名が「bob」の場合、結果は LDAP 検索文字列「” (& (vpnallowed=true) (samaccount=bob) “」 になります。検索文字列を 2 組の二重引用符で囲みます。
auth_timeout Citrix ADC がサーバーからの応答を待機する秒数を指定します。デフォルト値は3です。
password_change パスワード変更要求を許可します。デフォルト値はDISABLEDです。
attributes_to_save LDAPサーバーからフェッチし、Citrix ADC上のセッションのキーと値のペアとして保存する必要がある、カンマで区切られた属性名のリスト。

認証ポリシー

authentication_policies を使用すると、認証メカニズムを適用するトラフィック選択基準を定義したり、選択したトラフィックに使用するプロバイダーを指定したりできます。

認証ポリシーでは、認証規則を指定できる2つの形式がサポートされています。

  • リソース形式
  • 式形式

リソース形式のポリシーには、次の属性があります。

属性 説明
path 特定の API エンドポイントを参照する URL パスプレフィックスの配列。例:/api/v1/products/
method HTTP メソッドの配列。許可される値は、GET、PUT、POST、または削除です。受信要求 URI がいずれかのパスおよびリストされたメソッドのいずれかに一致する場合、トラフィックが選択されます。方式が指定されない場合、トラフィック選択基準にはパスのみが使用されます。
provider 使用する必要のある認証メカニズムを指定します。認証メカニズムが提供されない場合、認証は実行されません。

式形式の認証ポリシーには、次の属性があります。

属性 説明
expression 認証に基づいて評価されるCitrix ADCの式を指定します
provider 使用する必要のある認証メカニズムを指定します。認証メカニズムが提供されない場合、認証は実行されません。

注:

特定のエンドポイントの認証をスキップする場合は、 provider 属性を空のリストとして設定したポリシーを作成します。それ以外の場合、要求は拒否されます。

承認ポリシー

承認ポリシーでは、トラフィック選択基準を定義して、選択したトラフィックに承認要件を適用できます。

承認ポリシーでは、承認規則を指定できる2つの形式がサポートされています。

  • リソース形式
  • 式形式

リソース形式の承認ポリシーには、次の属性があります。

属性 説明
path 特定の API エンドポイントを参照する URL パスプレフィックスの配列。例:/api/v1/products/
method HTTP メソッドの配列。許可される値は、GET、PUT、POST、またはDELETEです。
claims 特定の API エンドポイントへのアクセスに必要なクレームを指定します。nameはクレーム名を示し、valuesは必要な権限を示します。複数のクレームを持つことができます。空のリストが指定された場合は、承認が不要であることを意味する。
  注: 承認に使用する必要のあるクレームは、認証の一部として保存する必要があります。

式形式の承認ポリシーには、次の属性があります。

属性 説明
expression 承認のために評価される式を指定します。

注:

Citrix ADC では、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
    

認証ポリシーと承認ポリシーの作成方法

Citrix が提供する CRD を Kubernetes クラスターに展開したら、認証ポリシー構成を.yamlファイルで定義できます。.yamlファイルのkindフィールドでauthpolicyを使用し、specセクションで、ポリシー設定の要件に基づいてAuth CRD属性を追加します。

.yaml ファイルを展開すると、Citrix Ingress ControllerはIngress Citrix ADCデバイスに認証ポリシー構成を適用します。

ローカル認証プロバイダ

ローカル認証プロバイダータイプ (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: []

サンプルポリシー定義では、次の処理が実行されます。

  • Citrix ADCは、次の要求に対してローカル認証を実行します。
    • 注文および出荷エンドポイントに対するGETまたは POST 操作。
  • Citrix ADC は、 **製品エンドポイントでGET操作の認証を実行しません** 。
  • Citrix ADC は承認権限を適用しません。

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: []

サンプルポリシー定義では、次の処理が実行されます。

  • Citrix ADCは、次の要求に対してJWT検証を実行します。

    • 注文および出荷 エンドポイントに対するGETまたは POST操作。
  • Citrix ADCは、製品エンドポイントでのGET操作の認証をスキップします。

  • Citrix ADCでは、注文および出荷エンドポイントでPOST操作を行うためのスコープ要求とreadおよびwrite権限が必要です 。

  • Citrix ADC では、注文エンドポイントでのGET 操作に読み取り権限を持つスコープ要求が必要です。

  • Citrix ADCは、出荷エンドポイントでの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"]

サンプルポリシー定義では、次の処理が実行されます。

  • Citrix ADC は、すべての要求に対してプロバイダーintrospect-providerで指定されたとおりにOAuthイントロスペクションを実行します。

  • Citrix ADC では、 すべてのPOST要求に対するスコープ要求とreadおよびwrite権限が必要です 。

  • Citrix ADC では、すべての GET 要求に対して読み取り権限を持つスコープ要求が必要です。

イントロスペクション用のクライアント認証情報を持つシークレットオブジェクトの作成

OAuth イントロスペクションを設定するには、Kubernetes シークレットオブジェクトが必要です。 次の例に示すように、シークレットオブジェクトも同様の方法で作成できます。

apiVersion: v1        
kind: Secret          
metadata:             
  name: oauthsecret
type: Opaque        
stringData:           
 client_id: "nsintro"
 client_secret: "nssintro"

注:

Opaque Secret オブジェクトのキーは、client_idおよびclient_secretである必要があります 。ユーザーはこれらの値を必要に応じて設定できます。

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

フォームを使用した SAML 認証の例を次に示します。この例では、authhost-tls-cert-secretsaml-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: []

<!--NeedCopy-->

サンプルポリシー定義では、次の処理が実行されます。

  • Citrix ADCは、すべての要求に対してプロバイダーsaml-auth-providerで指定されているとおりにSAML認証を実行します。 注: フォームメカニズムでは、きめ細かな認証はサポートされていません。

  • Citrix ADCでは、すべてのPOST要求に対してadmin権限を持つグループ要求が必要です

  • Citrix ADC は、 GET 要求に対して特定の権限を必要としません。

フォームを使った OpenID コネクト認証

以下は、OpenID Connect認証を作成して、Citrix ADCを中継者(RP)の役割で構成し、外部IDプロバイダーのユーザーを認証する例です。OpenID Connectプロシージャをトリガーするには、authentication_mechanismusing_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: []
<!--NeedCopy-->

サンプルポリシー定義では、次の処理が実行されます。

  • Citrix ADCは、すべての要求に対してプロバイダーoidc-providerで指定されているOIDC認証(証明書利用者)を実行します。

    注: フォームメカニズムでは、きめ細かな認証はサポートされていません。

  • Citrix ADCには認証権限は必要ありません。

リクエストヘッダーを使用した 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: []
<!--NeedCopy-->

注: リクエストヘッダーベースの認証メカニズムでは、トラフィックに基づくきめ細かな認証がサポートされます。

フォームを使用した 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: []

<!--NeedCopy-->

サンプルポリシー定義では、次の処理が実行されます。

  • Citrix ADCは、トラフィック全体(すべての要求)に対してLDAP認証を実行します。
  • Citrix ADC は承認許可を適用しません。

以下はLDAP_secret.yamlの例です。

apiVersion: v1
kind: Secret
metadata:
  name: ldapcredential
type: Opaque
stringData:
  username: 'ldap_server_username'
  password: 'ldap_server_password'

<!--NeedCopy-->

Auth CRDを使用したCitrix ADC式のサポートの例

この例は、認証および承認ポリシーとともにCitrix ADC式を指定する方法を示しています。

  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")'
Citrix ADCを使用したKubernetesの認証および承認ポリシー