S3Aコネクタは、S3へのリクエストを監査するための拡張ポイントを提供します。監査は、すべてのFS操作のエントリポイントで、そしてAWS S3 SDK内で、リクエストが実行される直前に実行できます。
完全なアーキテクチャは監査アーキテクチャで説明されています。このドキュメントでは、その使用方法について説明します。
ThreadLocalフィールドの使用によるメモリリークのため、この監査機能は、S3Aファイルシステムインスタンスが作成および削除されるとメモリリークが発生していました。これは、ファイルシステムインスタンスを再利用しない、または特定のユーザーに属するすべてのインスタンスを削除しようとする長期実行プロセスで問題を引き起こしていました。HADOOP-18091 S3A監査はThreadLocal参照を介してメモリリークが発生しますを参照してください。
これらのメモリリークを回避するために、hadoop 3.3.2リリースでは、監査はデフォルトで無効化されました。
これらのメモリリークが修正されたため、監査が再び有効になりました。
無効にするには、fs.s3a.audit.enabledをfalseに設定します。
したがって、監査サービスをプラグインして、（ベストエフォートによる）監査とヒントによる許可/拒否セキュリティを提供できます。
これは、S3リソースへのアクセスを制御する手段ではありません。これは、FileSystem操作API呼び出しのログ記録をサポートするためのベストエフォートであり、特に、単一のFS API呼び出しで複数のオブジェクトリクエストをS3に関連付け、理想的には負荷を生成するプロセス/ジョブを識別することです。
監査はデフォルトで無効になっています。監査が有効になっている場合、ログ監査は、S3に行われたリクエストでカスタムHTTPリファラーヘッダーを通じてS3ログに注釈を付けます。代わりに他の監査クラスを使用することもできます。
| オプション | 意味 | デフォルト値 |
|---|---|---|
fs.s3a.audit.enabled |
監査は有効ですか？ | true |
fs.s3a.audit.service.classname |
監査クラス名 | org.apache.hadoop.fs.s3a.audit.impl.LoggingAuditor |
fs.s3a.audit.request.handlers |
ハンドラーチェーンに含めるAWS SDK RequestHandler2の追加サブクラスのリスト | "" |
fs.s3a.audit.referrer.enabled |
HTTPリファラーヘッダーに監査情報を公開するログ監査 | true |
fs.s3a.audit.referrer.filter |
フィルタリングする監査フィールドのリスト | "" |
fs.s3a.audit.reject.out.of.span.operations |
スパン外の操作を拒否する監査 | false |
このHadoopリリースでは、監査は無効になっています。
これは、グローバルに、または特定のバケットに対して明示的に設定できます。
<property> <name>fs.s3a.audit.enabled</name> <value>false</value> </property>
グローバルに有効になっている場合でも、特定のバケットで監査を無効にすることができます。
<property> <name>fs.s3a.bucket.landsat-pds.audit.enabled</name> <value>false</value> <description>Do not audit landsat bucket operations</description> </property>
「ログ監査」はデフォルトの監査です。2種類のログを提供します。
ログ監査は、オプションfs.s3a.audit.service.classnameにクラス名を提供することで有効になります。
<property> <name>fs.s3a.audit.enabled</name> <value>true</value> </property> <property> <name>fs.s3a.audit.service.classname</name> <value>org.apache.hadoop.fs.s3a.audit.impl.LoggingAuditor</value> </property>
ローカルクライアントログに監査イベントを出力するには、関連付けられたLog4Jログをデバッグでログに記録するように設定します。
# Auditing log4j.logger.org.apache.hadoop.fs.s3a.audit.impl.LoggingAuditor=DEBUG
AWS S3バケットは、バケットに行われたすべてのHTTPリクエストのログを別のS3バケットに保存するように構成できます。S3サーバーアクセスログログ監査では、すべてのAWS S3リクエストのHTTPrefererフィールドが、コンテキストとスパン情報を提供するURLに構築されます。このフィールドはS3ログに保存されるため、S3バケットログが有効になっている場合、ログはS3クライアントによるアクセスを実際に発生している操作に関連付けることができます。
注：このログは「ベストエフォート」として記述されています。ログがいつ到着するかについての保証はありません。
ログ監査は、監査されたスパンの外でS3へのリクエストが行われるたびに例外を発生させるように構成できます。つまり、S3AFileSystemインスタンス（監査を作成したインスタンス）を介してS3と対話するスレッドは、アクティブなスパンがありません。
これは主に開発用であり、パブリックAPI呼び出しを通じてスパンが入力されていることを保証するために使用できます。
<property> <name>fs.s3a.audit.reject.out.of.span.operations</name> <value>true</value> </property>
この拒否プロセスは、一部のAWS S3リクエストクラスに対して無効になっています。これらのクラスは、より大規模な操作の一部としてAWS SDK内で作成され、スパンをアタッチできません。
| 常に許可されるAWSリクエスト | 理由 |
|---|---|
GetBucketLocationRequest |
AWS SDKで使用され、S3エンドポイントを決定します。 |
CopyPartRequest |
AWS SDKのコピー操作中に使用されます。 |
CompleteMultipartUploadRequest |
AWS SDKで使用され、コピー操作を完了します。 |
コピー/マルチパートアップロードを開始するリクエストは常に監査されるため、監査プロセスは名前変更とマルチパートIOのカバレッジを持っています。ただし、AWS S3ログには、関連付けられたコピー/完了呼び出しのリファラーヘッダーに完全なトレース情報は含まれません。
HTTPリファラーヘッダーは、ログ監査によって添付されます。S3バケットが別のバケットへのリクエストをログに記録するように構成されている場合、これらのログエントリには、リファラーとして監査情報が含まれます。
これは解析でき（正規表現についてはAWSのドキュメントを参照）、HTTPリファラーヘッダーを抽出できます。
https://audit.example.org/hadoop/1/op_rename/3c0d9b7e-2a63-43d9-a220-3c574d768ef3-3/
?op=op_rename
&p1=s3a://alice-london/path1
&pr=alice
&p2=s3a://alice-london/path2
&ps=235865a0-d399-4696-9978-64568db1b51c
&ks=5
&id=3c0d9b7e-2a63-43d9-a220-3c574d768ef3-3
&t0=12
&fs=af5943a9-b6f6-4eec-9c58-008982fc492a
&t1=12
&ts=1617116985923
リクエストで見つけることができるフィールドを次に示します。フィールド値がnullの場合、フィールドは省略されます。
| 名前 | 意味 | 例 |
|---|---|---|
cm |
コマンド | S3GuardTool$BucketInfo |
fs |
ファイルシステムID | af5943a9-b6f6-4eec-9c58-008982fc492a |
id |
スパンID | 3c0d9b7e-2a63-43d9-a220-3c574d768ef3-3 |
ji |
ジョブID（S3Aコミッター） | （クエリエンジンによって生成） |
op |
ファイルシステムAPI呼び出し | op_rename |
p1 |
操作のパス1 | s3a://alice-london/path1 |
p2 |
操作のパス2 | s3a://alice-london/path2 |
pr |
プリンシパル | alice |
ps |
一意のプロセスUUID | 235865a0-d399-4696-9978-64568db1b51c |
rg |
GETリクエスト範囲 | 100-200 |
ta |
タスク試行ID（S3Aコミッター） | |
t0 |
スレッド0：スパンが作成されたスレッド | 100 |
t1 |
スレッド1：この操作が実行されたスレッド | 200 |
ts |
タイムスタンプ（UTCエポックミリ秒） | 1617116985923 |
ks |
与えられたリクエストの一部として削除するキーサイズ（ファイル数）（削除と名前変更の操作に適用可能） | 5 |
備考
Long.toString(Thread.currentThread().getId())
t0とt1が異なる場合、元の操作に代わって別のスレッドに処理が引き継がれたことを意味します。これはクライアント側のログエントリと関連付けることで、特定のスレッドへの作業を分離できます。
ヘッダーの長さにはサイズ制限があります。長いパスの操作では、この制限を超える可能性があります。そのような状況では、監査ログが不完全になります。
そのため、span IDはHTTPクエリパラメータだけでなく、常にURLの一部として渡されます。ヘッダーが切り詰められても、span IDは常に存在するからです。
S3AクライアントがS3バケットにリクエストを行うと、監査者はヘッダーにspan情報を追加し、それがログに保存されます。
S3バケットがクライアントと同じ組織が所有している場合、このspan情報は組織内部の情報です。
S3バケットが別のエンティティによって所有/管理されている場合、そのエンティティによって収集されたS3バケットログにspan情報が表示されます。これには、プリンシパル名と、アプリケーションがToolsまたはサービスランチャーAPIを介して起動された場合に実行されたコマンドが含まれます。
この情報の共有は、特定のヘッダーをフィルタリングするか、Refererヘッダーの生成全体を明示的に無効にすることで無効にできます。
注：HTTP Refererが無効になっている場合、またはプリンシパルがフィルタリングされている場合でも、AWS S3ログにはリクエストを行ったユーザーまたはIAMロールのARNが含まれます。
Refererヘッダーから特定のフィールドをフィルタリングできるため、S3Aログに含まれません。
<property> <name>fs.s3a.audit.referrer.filter</name> <value>pr, cm</value> <description>Strip out principal and command from referrer headers</description> </property>
ログ監査者は、オプションfs.s3a.audit.referrer.enabledをfalseに設定することで、グローバルに、または特定のバケットに対してRefererヘッダーを追加しないように設定できます。
<property> <name>fs.s3a.audit.referrer.enabled</name> <value>false</value> <description>Disable referrer for all buckets</description> </property> <property> <name>fs.s3a.bucket.landsat-pds.audit.referrer.enabled</name> <value>false</value> <description>Do not add the referrer header to landsat operations</description> </property>
S3バケットは、サーバーアクセスロギング用に設定する必要があります。
これにより、AWS S3はすべてのHTTPリクエストのアクセスログを収集し、同じリージョンの別のバケットに保存します。ログは、数秒分のログデータを含むファイルとして到着し、設定されたパス下に保存されます。
logs/$BUCKET/log-のようなプレフィックスを使用して、異なるバケットのログを分離します。たとえば、dev data londonからのログデータのパスはs3://london-log-bucket/logs/dev-data-lon/log-になります。）S3リクエストが行われてからログが表示されるまでに約1時間遅延があります。設定中に動作していないように見えても心配しないでください。ログを有効にし、「hadoop fs」コマンドラインを介してバケットを操作し、1時間待ってから、ログバケットにエントリがないか確認します。ログファイル名には、これらのログが開始された時間が含まれています。
ログはS3バケットに保存されるため、これも料金が発生します。一定期間後にログを削除するか、ワークフローを設定してログエントリを圧縮形式およびより大きなファイルにロードして統合することで、コストを抑えましょう。
古いログファイルを自動的に削除するルールを設定するのは簡単です。
london-log-bucket）を表示します。logs/を追加して、すべてバケットのすべてのログを削除します。重要：/logs/など、先頭に「/」を含めてはいけません。一致せず、ルールは機能しません。削除が機能していることを確認するためにバケットを監視してください。プレフィックスでエラーを起こしやすいので、ログは制限なく作成されるため、コストが急上昇します。
AWS S3ドキュメントはログ形式について説明しており、これを使用するためのHive外部テーブル宣言が含まれています。
hadoop-awsテストスイートでヘッダーを抽出するために使用されるJavaパターン正規表現は、次のように定義されています。
(?<owner>[^ ]*) (?<bucket>[^ ]*) (?<timestamp>\[(.*?)\]) (?<remoteip>[^ ]*) (?<requester>[^ ]*) (?<requestid>[^ ]*) (?<operation>[^ ]*) (?<key>[^ ]*) (?<requesturi>(-|"[^"]*")) (?<http>(-|[0-9]*)) (?<awserrorcode>[^ ]*) (?<bytessent>[^ ]*) (?<objectsize>[^ ]*) (?<totaltime>[^ ]*) (?<turnaroundtime>[^ ]*) (?<referrer>(-|"[^"]*")) (?<useragent>(-|"[^"]*")) (?<version>[^ ]*) (?<hostid>[^ ]*) (?<sigv>[^ ]*) (?<cypher>[^ ]*) (?<auth>[^ ]*) (?<endpoint>[^ ]*) (?<tls>[^ ]*)*$
クラスorg.apache.hadoop.fs.s3a.audit.S3LogParserは、このパターンと各グループの定数を提供します。これはPublic/Unstableとして宣言されています。
org.apache.hadoop.fs.s3a.auditログコンテキストには、監査を実装するさまざまなコンポーネントのログが含まれています。
LoggingAuditServiceを使用して監査されたリクエストのロギングは、そのログをデバッグに設定することで有効にできます。
# Log before a request is made to S3 log4j.logger.org.apache.hadoop.fs.s3a.audit.impl.LoggingAuditor=DEBUG
これにより、リクエストごとに1行のログが追加され、S3AクライアントとAWS S3間の通信に関するいくつかの洞察が得られます。
スパンの開始と終了など、監査システムの低レベルのデバッグには、ログをTRACEに設定します。
# log request creation, span lifecycle and other low-level details log4j.logger.org.apache.hadoop.fs.s3a.audit=TRACE
これは非常にノイズが多く、通常の運用では推奨されません。
S3Aコミッターを介して送信された作業には、そのスレッド内のすべてのS3Aファイルシステムに対して行われるS3操作に関連付けられたジョブ（クエリ）IDがあります。
これを有効にするには、タスクで実行される作業は、コミッターでjobSetup()またはtaskSetup()を呼び出したのと同じスレッド内にある必要があります。