Kerberos認証の使用
ファイル・ストレージ・サービスは、強力な認証オプションを提供するKerberos認証を提供します。
NFS v.3 Unixセキュリティーは、NFSクライアントがユーザーの識別情報について真実であることを信頼し、基本的なセキュリティーのみを提供します。すべてのNFS呼び出しにおけるユーザーの識別情報は呼び出し元によって定義され、その識別情報は信頼できるサードパーティーによって検証されません。
NFSv3のKerberosは、ホストとユーザーの両方に強力な認証を提供します。また、データの整合性を証明し、データの改ざんがないことを確認し、データのプライバシを保護することもできます。NFS v.3 UNIXセキュリティでは、特殊なクライアント・ソフトウェアをインストールしたり、TCPポートを増やすことなく、データの整合性とデータ・プライバシを確保することはできません。
- Kerberos対応ネットワーク内のユーザーおよびサービスは、主体と呼ばれます。Kerberos主体の形式は
primary/instance@realmです。詳細は、MIT Kerberosプリンシパルのドキュメントを参照してください。 - キー配布センター(KDC)はプリンシパルを認証し、チケットを発行します。KDCは主体とそのパスワードのリストを保持します。
- レルムは、1つのKDCでサポートされているすべての主体で構成されます。
ファイル・ストレージ・サービスでは、RPCSEC_GSS (RFC2203)を介したKerberos認証が次のセキュリティ・オプションとともにサポートされます:
- NFSを介した認証にモード
KRB5を使用 - NFSを介した認証およびデータ整合性(転送中のデータの不正変更)にモード
KRB5Iを使用します - NFSを介した認証、データ整合性およびデータ・プライバシ(転送中暗号化)にはモード
KRB5Pを使用します
機能
Kerberosのファイル・ストレージ・サービスのサポートには、次の機能が含まれます。
転送中暗号化
TLS v.1.2 (Transport Layer Security)暗号化を使用する代わりに、データのプライバシを提供する Kerberosモード KRB5Pを使用できます。TLS v.1.2暗号化では、オペレーティング・システムに応じて、oci-fss-utilsというパッケージをインストールするか、またはstunnelを使用する必要があります。マウント・ターゲットの暗号化NFS/TLS接続の数は制限されていますが、KerberosをKRB5Pオプションとともに使用すると、NFS over TLSでは不可能なスケールで転送中暗号化を使用できます。
IPによるKerberosとセキュリティ
IPアドレスがOCIにあり、ホストが信頼できる場合、NFSエクスポート・オプションを使用して設定されたIPによるセキュリティはかなり安全です。NFSv3用のKerberosは、信頼できないホストを持つ混合環境または環境に対して、より高いレベルのセキュリティを提供できます。
1つのCIDRブロックを構成して、同じエクスポートでKerberosとNFS AUTH_SYS認証を要求できます。信頼できるネットワークからマウントするクライアントは Kerberosを使用してマウントする必要はありませんが、信頼できないネットワークからマウントするクライアントは Kerberosを使用する必要があります。
LDAP参照および匿名アクセス
ユーザーがKDCにアイデンティティーを持っているが、LDAPサーバーに追加情報がない、またはLDAPが有効になっていない場合、NFSの操作は失敗するか続行できます。このような場合の動作は、マウント・ターゲットに対してLDAPを有効にするか、エクスポートに対して匿名アクセスを有効にするかによって異なります。
匿名アクセスはデフォルトで無効になっています。見つからないユーザーに関連付けられたNFSリクエストは失敗します。
匿名アクセスが有効になっている場合、LDAPサーバーで見つからないユーザーに関連付けられたリクエストは、エクスポートのオプションで設定された「Squash UID」および「Squash GID」に進みます。LDAPサーバーに存在しないシステム Kerberos主体をマウントプロセスで使用し、破棄された権利によってNFSクライアントがファイルシステムをマウントするために使用するいくつかの読み取り専用操作が許可されている場合は、匿名アクセスを許可することをお勧めします。
| マウント・ターゲットでLDAPが有効になっていますか。 | LDAPレスポンス | 匿名アクセス有効? | スカッシュのエクスポートが有効ですか? | NFSリクエスト |
|---|---|---|---|---|
| 任意 | 任意 | 任意 | はい(すべて) |
エクスポートのオプションに「Squash UID」および「Squash GID」が設定された状態で続行します。セカンダリ・グループ・リストがありません。 |
| 任意 | 任意 | 任意 | はい(ルート) |
ユーザー名がUID 0にマップされているLDAPレスポンスが成功した後にのみ、エクスポートのオプションに設定された「Squash UID」および「Squash GID」に進みます。セカンダリ・グループ・リストがありません。 LDAP応答が0以外のUIDを返した場合は、返されたUID、GID、およびグループリストに進みます。 |
| はい | USERNAMEが一致しました | 任意 | いいえ | LDAPサーバーから取得されたUID、GID、およびセカンダリグループリストを使用します。 |
| はい | USERNAMEが一致しません | はい | いいえ | エクスポートのオプションに「Squash UID」および「Squash GID」が設定された状態で続行します。セカンダリ・グループ・リストがありません。 |
| はい | USERNAMEが一致しません | いいえ | いいえ | 権限エラーで失敗します。 |
| はい | 一致するユーザー以外のLDAPエラー | 任意 | いいえ | 権限エラーで失敗します。 |
| いいえ | 適用なし | はい | いいえ |
エクスポートのオプションに「Squash UID」および「Squash GID」が設定された状態で続行します。 |
| いいえ | 適用なし | いいえ | いいえ | 権限エラーで失敗します。 |
Kerberos対応エクスポートでは、マウント・ターゲットで「LDAPの有効化」が有効になっている場合、常に「LDAPをグループ・リストに使用」が使用されます。
詳細は、NFSエクスポート・オプションを参照してください。
前提条件
ファイル・ストレージで認証にKerberosを使用するには、いくつかの前提条件が必要です。
ユーザーごとに Kerberos認証を使用するための要件は次のとおりです。
- Kerberos主体をUNIX IDにマップするための顧客管理のLDAPインフラストラクチャ。詳細は、LDAP for Authorizationの前提条件を参照してください。
- MITや Microsoft Active DirectoryなどのKDCを使用した顧客管理 Kerberosインフラストラクチャ。
- マウント・ターゲット名とIPアドレスを解決できるDNSサーバー。フォワード参照機能とリバース参照機能の両方が必要です。
- TCP/UDPポート88経由で顧客管理KDCサーバーとの通信。
- NFSポート2048/2049/2050 (オプションで暗号化)を介したKerberos対応マウント・ターゲットとのセキュアな通信。
- TCP/UDPポート53を介したDNSサービスとの通信。
- アウトバウンド・コネクタで構成されたTCPポートを介した顧客管理LDAPサービスとの通信。デフォルト値は、TCPポート636です。
- ファイル・ストレージでの保存データの暗号化。
LDAPインフラストラクチャ
ファイル・ストレージは、UIDおよびGIDを使用してファイルへのアクセスを認可します。ファイル・ストレージでは、LDAPを使用してKerberosプリンシパルをUIDおよびGIDSにマップします。LDAPインフラストラクチャ要件の詳細は、認可のためにLDAPを使用するための前提条件を参照してください。
ファイル・ストレージがLDAPから認可情報を検索できない場合、KerberosプリンシパルのNFSアクセスが失敗する可能性があります。Kerberos認証はLDAPなしでも使用できますが、認証されたすべての Kerberos主体は匿名として扱われます。詳細は、LDAP Lookups and Anonymous Accessを参照してください。
Kerberos Keytab
OCI Vaultに格納されているKerberos keytabは、次の構造のBase64-encoded文字列配列である必要があります:
<principal, key version number, cipher type, symmetric key>keytabの各エントリは1つの主体のみを持つことができ、その主体にはそのインスタンスとしてマウントターゲットの完全修飾ドメイン名(FQDN)を含める必要があります。1つの主体は、異なる暗号化タイプまたは暗号を持つ複数のエントリを持つことができます。
たとえば、nfs/krb_mt1.fss_test.com@FSS_EXAMPLE.COMがkeytabのプリンシパルである場合、FSS_EXAMPLE.COMはレルム、fss_test.comはインスタンス、nfsはプライマリです。この例のマウント・ターゲットのFQDNはkrb_mt1.fss_test.comである必要があります。顧客管理DNSサーバーを使用する場合は、このFQDNをマウント・コマンドで使用します。
デフォルトのInternet and VCN Resolverを使用する場合、ファイル・ストレージ・サービスは、マウント・ターゲットのホスト名とマウント・ターゲットが存在するサブネットのFQDNを組み合せてFQDNを構築します。ホスト名は、作成後にマウント・ターゲットの詳細ページで変更できます。詳細は、マウント・ターゲットの管理を参照してください。
ファイル・ストレージでは、次の暗号セットがサポートされています:
- aes128-cts-hmac-sha256-128
- aes256-cts-hmac-sha384-192
- aes128-cts-hmac-sha1-96
- aes256-cts-hmac-sha1-96
OCI ファイル・ストレージでは、最大1024バイトのKerberosキータブ・サイズがサポートされます。
Kerberosを有効にする前にKerberosキータブを検証して、無効なkeytabが原因の可用性停止を回避します。キータブは、マウント・ターゲットのKerberos構成を構成または確認するときに検証できます。
コンソール、CLIまたはAPIを介してKerberosキータブを検証すると、ファイル・ストレージ・サービスによって次がチェックされます:
- keytabサイズが1024バイトより大きい場合
- keytabバージョン番号が1281または1282でないこと
- keytabにnullのエントリが含まれている場合
- keytabに異なる主体名のエントリがある場合
- keytabに12を超えるエントリがある場合(最大)
- keytabエンコーディングタイプが次のいずれかでない場合:
- ETYPE_AES128_CTS_HMAC_SHA1_96
- ETYPE_AES256_CTS_HMAC_SHA1_96
- ETYPE_AES128_CTS_HMAC_SHA256_128
- ETYPE_AES256_CTS_HMAC_SHA384_192
KDCからバイナリ形式で抽出されたキータブは、Base64に変換してから、OCI Vaultでシークレットを作成するために使用する必要があります。変換されたキータブに貼り付けるときは、必ずシークレットの形式としてBase64を選択してください。
ファイル・ストレージでは、バックアップkeytabを使用したkeytabローテーションがサポートされています。詳細は、キーのローテーションを参照してください。
考慮事項および制限
ファイル・ストレージ認証にKerberosを使用する場合は、次の情報および制限を考慮してください。
- ユーザーごとのKerberos認証の場合、ファイル・ストレージには、RFC2307 POSIXスキーマをサポートするLDAPサーバーを含む、顧客管理のLightweight Directory Access Protocol (LDAP)インフラストラクチャが必要です。
- ファイル・ストレージでは、最大1024バイトのKerberosキータブ・サイズがサポートされます。
-
ファイル・ストレージでは、次の暗号セットがサポートされています:
- aes128-cts-hmac-sha256-128
- aes256-cts-hmac-sha384-192
- aes128-cts-hmac-sha1-96
- aes256-cts-hmac-sha1-96
rsizeまたはwsizeオプションを指定してファイルシステムをマウントすることはお勧めしません。これらのオプションの値を指定する場合、KRB5IまたはKRB5Pを使用するときは、ファイル・ストレージによって256KBに減らすことができます。- Kerberos認証モード
KRB5を使用する場合のファイル・ストレージのパフォーマンスは、AUTH_SYS認証の使用とほぼ同等です。KRB5Pを使用するとパフォーマンスが大幅に低下し、KRB5Iを使用するとパフォーマンスがわずかに低下します。パフォーマンスは、クライアント構成およびファイルシステムによって異なる場合があります。
モニタリングとアラーム
LDAP認証で Kerberos認証を使用する場合は、問題を迅速に認識することが重要です。KerberosまたはLDAPインフラストラクチャが正しく機能しない場合、NFSクライアントは、エクスポートを介して使用可能なファイル・ストレージ・ファイル・システムへのアクセスを失う可能性があります。このような問題を検出するには、マウント・ターゲットのメトリックにアラームを設定することをお薦めします。アラームは、数分以内にインフラストラクチャの問題を警告できます。
Kerberosエラー、LDAP接続エラーおよびLDAPリクエスト・エラーから構築されたアラームは、マウント・ターゲット、アウトバウンド・コネクタおよび顧客管理LDAPインフラストラクチャ間の接続の問題を検出します。
次のクエリー例を使用すると、Kerberosエラーのアラームを作成できます。
KerberosErrors[1m]{resourceType = "mounttarget", mtResourceName = "<mount_target_name>", errorType != "keytab_load_success"}.max() >= 1次のクエリー例を使用すると、LDAP接続用のアラームを作成できます。
LdapConnectionErrors[1m]{resourceType = "outboundconnector", mtResourceName = "<mount_target_name>", errorType != "success"}.max() >= 1必須IAMポリシー
ファイル・ストレージは、Kerberos構成のLDAPサーバー・パスワードにアクセスし、ターゲットのKerberosキータブVaultシークレットをマウントする必要があります。マウント・ターゲットを構成するユーザーとマウント・ターゲット自体の両方に読取りアクセスが必要です。
Vaultシークレットを管理するためのポリシー
Vaultシークレット権限を作成するユーザーまたはグループに付与します。詳細は、Vaultシークレットの管理を参照してください。
マウント・ターゲット構成を有効にするポリシー
次のようなポリシーを使用して、マウント・ターゲットに対するKerberosおよびLDAPの構成をユーザーまたはグループに付与します:
allow <user|group> to read secret-family in compartment <Compartment_ID> where any { target.secret.id = <Keytab_Secret_ID>, target.secret.id = <LDAP_Password_Secret_ID> }これにより、ユーザーはVaultシークレットを読み取り、検証のためにシークレットの一部を表示するファイル・ストレージ・コマンドを発行できます。ファイル・ストレージは、検証のためにマウント・ターゲットを構成しているユーザーにプリンシパル、キー・バージョン番号および暗号化タイプを示します。
マウント・ターゲットにシークレットの取得を許可するポリシー
ファイル・ストレージ・サービスには、シークレットを読み取る機能が必要です。ファイル・ストレージでは、リソース・プリンシパルを使用して、特定のマウント・ターゲットのセットにVaultシークレットへのアクセス権を付与します。これは2ステップのプロセスです。まずアクセスが必要なマウント・ターゲットを動的グループに配置し、次に動的グループにシークレットを読み取るためのアクセス権が付与されます。
-
次のようなポリシーを使用して、マウント・ターゲットの動的グループを作成します:
ALL { resource.type='mounttarget', resource.compartment.id = '<mount_target_compartment_id>' }ノート
動的グループに複数のルールがある場合は、必ずMatch any rules defined belowオプションを使用してください。 -
マウント・ターゲットの動的グループにVaultシークレットへの読取りアクセス権を付与するIAMポリシーを作成します:
allow dynamic-group <dynamic_group_name> to read secret-family in compartment <secret_compartment_name>
次のステップ
次の手順については、Setting Up Kerberos Authenticationを参照してください。