CKS 試験問題 31
コンテクスト：
クラスター: 本番環境
マスターノード: master1
ワーカーノード:worker1
次のコマンドを使用して、クラスター/構成コンテキストを切り替えることができます。
[desk@cli] $ kubectl config use-context prod
タスク：
指定された Dockerfile を分析して編集します (ubuntu:18:04 イメージに基づく)
/home/cert_masters/Dockerfile は、セキュリティ/ベスト プラクティスに関する顕著な問題であるファイル内に存在する 2 つの命令を修正します。
指定されたマニフェスト ファイルを分析して編集します
/home/cert_masters/mydeployment.yaml は、顕著なセキュリティ/ベスト プラクティスの問題であるファイル内に存在する 2 つのフィールドを修正します。
注: 構成設定を追加または削除しないでください。既存の構成設定を変更するだけなので、2 つの構成設定はそれぞれセキュリティ/ベスト プラクティスの問題ではなくなります。
いずれかのタスクに特権のないユーザーが必要な場合は、ユーザーID 65535のユーザーnobodyを使用してください。
クラスター: 本番環境
マスターノード: master1
ワーカーノード:worker1
次のコマンドを使用して、クラスター/構成コンテキストを切り替えることができます。
[desk@cli] $ kubectl config use-context prod
タスク：
指定された Dockerfile を分析して編集します (ubuntu:18:04 イメージに基づく)
/home/cert_masters/Dockerfile は、セキュリティ/ベスト プラクティスに関する顕著な問題であるファイル内に存在する 2 つの命令を修正します。
指定されたマニフェスト ファイルを分析して編集します
/home/cert_masters/mydeployment.yaml は、顕著なセキュリティ/ベスト プラクティスの問題であるファイル内に存在する 2 つのフィールドを修正します。
注: 構成設定を追加または削除しないでください。既存の構成設定を変更するだけなので、2 つの構成設定はそれぞれセキュリティ/ベスト プラクティスの問題ではなくなります。
いずれかのタスクに特権のないユーザーが必要な場合は、ユーザーID 65535のユーザーnobodyを使用してください。
CKS 試験問題 32
シミュレーション
john という名前のユーザーを作成し、CSR リクエストを作成し、承認後にユーザーの証明書を取得します。
名前空間 john 内のシークレットとポッドをリストするロール名 john-role を作成します。
最後に、john-role-binding という名前の RoleBinding を作成し、新しく作成したロール john-role を名前空間 john 内のユーザー john にアタッチします。確認するには: kubectl auth CLI コマンドを使用して、アクセス許可を確認します。
john という名前のユーザーを作成し、CSR リクエストを作成し、承認後にユーザーの証明書を取得します。
名前空間 john 内のシークレットとポッドをリストするロール名 john-role を作成します。
最後に、john-role-binding という名前の RoleBinding を作成し、新しく作成したロール john-role を名前空間 john 内のユーザー john にアタッチします。確認するには: kubectl auth CLI コマンドを使用して、アクセス許可を確認します。
CKS 試験問題 33
次のコマンドを使用して、クラスター/構成コンテキストを切り替えることができます: [desk@cli] $ kubectl config use-context test-account タスク: クラスター内の監査ログを有効にします。
これを行うには、ログ バックエンドを有効にし、次のことを確認します。
1. ログは /var/log/Kubernetes/logs.txt に保存されます
2. ログ ファイルは 5 日間保持されます。
3. 最大で 10 個の古い監査ログ ファイルが保持されます。
基本ポリシーは /etc/Kubernetes/logpolicy/audit-policy.yaml で提供されます。ログに記録しないものを指定するだけです。注: 基本ポリシーはクラスターのマスター ノードにあります。
ログを記録する基本ポリシーを編集および拡張します。 1. RequestResponse レベルでのノードの変更 2. ネームスペース フロントエンドでの Persistentvolumes のリクエスト本文の変更 3. メタデータ レベルでのすべてのネームスペースでの ConfigMap と Secret の変更 また、キャッチオール ルールを追加します。他のすべてのリクエストをメタデータ レベルでログに記録します。 注: 変更したポリシーを適用することを忘れないでください。
これを行うには、ログ バックエンドを有効にし、次のことを確認します。
1. ログは /var/log/Kubernetes/logs.txt に保存されます
2. ログ ファイルは 5 日間保持されます。
3. 最大で 10 個の古い監査ログ ファイルが保持されます。
基本ポリシーは /etc/Kubernetes/logpolicy/audit-policy.yaml で提供されます。ログに記録しないものを指定するだけです。注: 基本ポリシーはクラスターのマスター ノードにあります。
ログを記録する基本ポリシーを編集および拡張します。 1. RequestResponse レベルでのノードの変更 2. ネームスペース フロントエンドでの Persistentvolumes のリクエスト本文の変更 3. メタデータ レベルでのすべてのネームスペースでの ConfigMap と Secret の変更 また、キャッチオール ルールを追加します。他のすべてのリクエストをメタデータ レベルでログに記録します。 注: 変更したポリシーを適用することを忘れないでください。
CKS 試験問題 34
シミュレーション
kubesec Docker イメージを使用して、指定された YAML マニフェストをスキャンし、推奨された変更を編集して適用し、4 ポイントのスコアで合格しました。
kubesec-test.yaml
APIバージョン: v1
種類: ポッド
メタデータ:
名前: kubesec-demo
仕様:
コンテナ:
- 名前: kubesec-demo
画像: gcr.io/google-samples/node-hello:1.0
セキュリティコンテキスト:
readOnlyRootFilesystem: true
ヒント: docker run -i kubesec/kubesec:512c5e0 scan /dev/stdin < kubesec-test.yaml
kubesec Docker イメージを使用して、指定された YAML マニフェストをスキャンし、推奨された変更を編集して適用し、4 ポイントのスコアで合格しました。
kubesec-test.yaml
APIバージョン: v1
種類: ポッド
メタデータ:
名前: kubesec-demo
仕様:
コンテナ:
- 名前: kubesec-demo
画像: gcr.io/google-samples/node-hello:1.0
セキュリティコンテキスト:
readOnlyRootFilesystem: true
ヒント: docker run -i kubesec/kubesec:512c5e0 scan /dev/stdin < kubesec-test.yaml
CKS 試験問題 35
次のコマンドを使用してクラスター/構成コンテキストを切り替えることができます: [desk@cli] $ kubectl config use-context stage コンテキスト: PodSecurityPolicy は、特定の名前空間での特権付き Pod の作成を防止します。タスク: 1. 特権付きポッドの作成を防止する、deny-policy という名前の新しい PodSecurityPolcy を作成します。2. 新しい ClusterRole という名前を作成し、deny-access-role という名前を付けます。これは、新しく作成された PodSecurityPolicy 拒否ポリシーを使用します。3. 既存の名前空間開発内に psd-denial-sa という名前の新しい ServiceAccount を作成します。最後に、restrict-access-bind という名前の新しい ClusterRoleBindind を作成します。これは、新しく作成された ClusterRole のdeny-access-role を、新しく作成された ServiceAccount psp-denial-sa にバインドします。