Second Japanese l10n work for release-1.16 (#19157)
* update install kubeadm related doc (#18826) * modify terminology mechanism (#19148)
This commit is contained in:
inductor
@@ -170,7 +170,7 @@ CRD、またはアグリゲートAPI、どちらを使ってカスタムリソ
|
||||
| merge-patch | 新しいエンドポイントが`Content-Type: application/merge-patch+json`を用いたPATCHをサポート |
|
||||
| HTTPS | 新しいエンドポイントがHTTPSを利用 |
|
||||
| ビルトイン認証 | 拡張機能へのアクセスに認証のため、コアAPIサーバー(アグリゲーションレイヤー)を利用 |
|
||||
| ビルトイン認可 | 拡張機能へのアクセスにコアAPIサーバーで使われている認可機構を再利用(例、RBAC) |
|
||||
| ビルトイン認可 | 拡張機能へのアクセスにコアAPIサーバーで使われている認可メカニズムを再利用(例、RBAC) |
|
||||
| ファイナライザー | 外部リソースの削除が終わるまで、拡張リソースの削除をブロック |
|
||||
| Admission Webhooks | 拡張リソースの作成/更新/削除処理時に、デフォルト値の設定、バリデーションを実施 |
|
||||
| UI/CLI 表示 | kubectl、ダッシュボードで拡張リソースを表示 |
|
||||
|
||||
@@ -121,7 +121,7 @@ Kubernetesはいくつかのビルトイン認証方式と、それらが要件
|
||||
|
||||
### 認可
|
||||
|
||||
[認可](/docs/reference/access-authn-authz/webhook/)は特定のユーザーがAPIリソースに対して、読み込み、書き込み、そしてその他の操作が可能かどうかを決定します。それはオブジェクト全体のレベルで機能し、任意のオブジェクトフィールドに基づいての区別は行いません。もしビルトインの認可機構が要件に合わない場合、[認可Webhook](/docs/reference/access-authn-authz/webhook/)が、ユーザー提供のコードを呼び出し認可の決定を行うことを可能にします。
|
||||
[認可](/docs/reference/access-authn-authz/webhook/)は特定のユーザーがAPIリソースに対して、読み込み、書き込み、そしてその他の操作が可能かどうかを決定します。それはオブジェクト全体のレベルで機能し、任意のオブジェクトフィールドに基づいての区別は行いません。もしビルトインの認可メカニズムが要件に合わない場合、[認可Webhook](/docs/reference/access-authn-authz/webhook/)が、ユーザー提供のコードを呼び出し認可の決定を行うことを可能にします。
|
||||
|
||||
### 動的Admission Control
|
||||
|
||||
|
||||
Reference in New Issue
Block a user