fix:add auditing section

content/ja/docs/concepts/security/controlling-access.md

@@ -14,7 +14,7 @@ APIアクセスには、人間のユーザーと[Kubernetesサービスアカウ
 
 ![Kubernetes APIリクエストの処理手順図](/images/docs/admin/access-control-overview.svg)
 
-## トランスポート層のセキュリティ
+## トランスポート層のセキュリティ {#transport-security}
 一般的なKubernetesクラスターでは、APIはTLSで保護された443番ポートで提供されます。
 APIサーバーは証明書を提示します。
 この証明書は、プライベート認証局(CA)を用いて署名することも、一般に認知されているCAと連携した公開鍵基盤に基づき署名することも可能です。
@@ -23,7 +23,7 @@ APIサーバーは証明書を提示します。
 
 クライアントは、この段階でTLSクライアント証明書を提示することができます。
 
-## 認証
+## 認証 {#Authentication}
 TLSが確立されると、HTTPリクエストは認証のステップに移行します。
 これは図中のステップ**1**に該当します。
 クラスター作成スクリプトまたはクラスター管理者は、1つまたは複数のAuthenticatorモジュールを実行するようにAPIサーバーを設定します。
@@ -41,7 +41,7 @@ Authenticatorについては、[認証](/ja/docs/reference/access-authn-authz/au
 
 Kubernetesはアクセスコントロールの決定やリクエストログにユーザー名を使用しますが、`User`オブジェクトを持たず、ユーザー名やその他のユーザーに関する情報をAPIはに保存しません。
 
-## 認可
+## 認可 {#Authorization}
 
 リクエストが特定のユーザーからのものであると認証された後、そのリクエストは認可される必要があります。
 これは図のステップ**2**に該当します。
@@ -93,7 +93,7 @@ Kubernetesは、ABACモード、RBACモード、Webhookモードなど、複数
 サポートされている認可モジュールを使用したポリシー作成の詳細を含む、Kubernetesの認可については、[認可](/docs/reference/access-authn-authz/authorization/)を参照してください。
 
 
-## アドミッションコントロール
+## アドミッションコントロール {#admission-control}
 アドミッションコントロールモジュールは、リクエストを変更したり拒否したりすることができるソフトウェアモジュールです。
 認可モジュールが利用できる属性に加えて、アドミッションコントロールモジュールは、作成または修正されるオブジェクトのコンテンツにアクセスすることができます。
 
@@ -111,8 +111,14 @@ Kubernetesは、ABACモード、RBACモード、Webhookモードなど、複数
 
 リクエストがすべてのアドミッションコントローラーを通過すると、対応するAPIオブジェクトの検証ルーチンを使って検証され、オブジェクトストアに書き込まれます(図のステップ**4**に該当します)。
 
+## 監査 {#Auditing}
 
-## APIサーバーのIPとポート
+Kubernetesの監査は、クラスター内の一連のアクションを文書化した、セキュリティに関連する時系列の記録を提供します。
+クラスターは、ユーザー、Kubernetes APIを使用するアプリケーション、およびコントロールプレーン自身によって生成されるアクティビティを監査します。
+
+詳しくは[監査](/docs/tasks/debug-application-cluster/audit/)をご覧ください。
+
+## APIサーバーのIPとポート {#api-server-ports-and-ips}
 
 これまでの説明は、APIサーバーのセキュアポートに送信されるリクエストに適用されます(典型的なケース)。
 APIサーバーは、実際には2つのポートでサービスを提供することができます。