ポリシークイズ
このクイズでは、ResourceQuota、LimitRange、PodSecurityPolicy、NetworkPolicy など、Kubernetes のポリシー概念についての理解を確認します。
選択問題
- Kubernetes における ResourceQuota の主な目的は何ですか？
- A) pod の CPU と memory 使用量を制限する
- B) namespace 内での resource 作成を制限する
- C) cluster 全体の resource 使用量を監視する
- D) node の resource 割り当てを管理する
答えを表示
答え: B) namespace 内での resource 作成を制限する
解説: ResourceQuota は、namespace 内で作成できる resource の総量を制限します。これには CPU や memory などの computing resource だけでなく、pod、service、configmap などの object 数も含まれます。ResourceQuota を使用すると、1 つの team が cluster resource をすべて独占することを防げます。
- LimitRange の主な機能は何ですか？
- A) namespace 全体の resource 使用量を制限する
- B) 個々の container に対するデフォルトの resource request と limit を設定する
- C) cluster node 間で resource を分配する
- D) pod 間の network 通信を制限する
答えを表示
答え: B) 個々の container に対するデフォルトの resource request と limit を設定する
解説: LimitRange は、namespace 内の pod または container に対する resource 制約を定義します。これにより、デフォルトの resource request と limit を設定したり、resource 使用量の最小値/最大値を強制したりできます。LimitRange は個々の resource に適用される一方、ResourceQuota は namespace 全体に適用されます。
- Kubernetes v1.25 で PodSecurityPolicy (PSP) が削除された後、どの mechanism がそれを置き換えましたか？
- A) PodSecurityStandards
- B) PodSecurityContext
- C) PodSecurityAdmission
- D) SecurityContextConstraints
答えを表示
答え: C) PodSecurityAdmission
解説: PodSecurityPolicy (PSP) は Kubernetes v1.25 で削除され、PodSecurityAdmission がそれを置き換えました。これは Pod Security Standards に基づく組み込みの admission controller で、Privileged、Baseline、Restricted の 3 つの policy level を提供します。PodSecurityContext は pod level で security 設定を構成するために使用され、SecurityContextConstraints は OpenShift で使用される類似の mechanism です。
- NetworkPolicy を使用してできないことは何ですか？
- A) 特定の namespace からの pod への traffic のみを制限する
- B) 特定の IP CIDR range への traffic のみを制限する
- C) 特定の port への traffic のみを制限する
- D) 特定 protocol の payload content を検査する
答えを表示
答え: D) 特定 protocol の payload content を検査する
解説: NetworkPolicy は、pod 間の通信を制御する L3/L4 level の firewall policy を提供します。これにより、特定の namespace、label、IP CIDR range、port などに基づいて traffic を制限できます。ただし、NetworkPolicy は L7 level の検査（例: HTTP header、payload content）を実行できません。そのような機能には、service mesh（例: Istio）または API gateway を使用する必要があります。
- Kubernetes における RBAC (Role-Based Access Control) の主な目的は何ですか？
- A) pod 間の network 通信を制御する
- B) user と service account の permission を管理する
- C) resource 使用量を制限する
- D) pod scheduling policy を設定する
答えを表示
答え: B) user と service account の permission を管理する
解説: RBAC (Role-Based Access Control) は、Kubernetes API への access を制御するための mechanism です。これにより、user、group、または service account が cluster 内で実行できる operation を定義できます。RBAC は Role、ClusterRole、RoleBinding、ClusterRoleBinding などの resource を使用して permission を管理します。
- Pod Security Standards の 3 つの policy level のうち、最も制限が厳しいものはどれですか？
- A) Privileged
- B) Baseline
- C) Restricted
- D) Enforced
答えを表示
答え: C) Restricted
解説: Pod Security Standards は 3 つの policy level を定義しています:
- Privileged: 制限なし、すべての privilege が許可される
- Baseline: 既知の privilege escalation 経路を防止する
- Restricted: 強化された security 設定が適用される、最も制限の厳しい policy
Restricted policy は最も制限が厳しく、least privilege の原則に従い、security best practice を適用します。この policy は privileged container、host namespace sharing、host path mount などを禁止します。
- Kubernetes における AdmissionController の役割は何ですか？
- A) user authentication
- B) resource 使用量の監視
- C) API request の検証と変更
- D) Pod scheduling
答えを表示
答え: C) API request の検証と変更
解説: AdmissionController は、authentication と authorization を通過した後、object が persistent storage に保存される前に、Kubernetes API server への request を intercept して検証または変更する plugin です。これにより、cluster administrator は resource の作成や変更に関する policy を適用できます。たとえば、PodSecurityAdmission、ResourceQuota、LimitRanger は AdmissionController として実装されています。
- Kubernetes における OPA (Open Policy Agent) Gatekeeper の主な機能は何ですか？
- A) Cluster monitoring と logging
- B) policy に基づく resource 管理と検証
- C) Auto scaling
- D) Service mesh management
答えを表示
答え: B) policy に基づく resource 管理と検証
解説: OPA Gatekeeper は、Kubernetes cluster に policy を適用するための拡張可能な solution です。OPA (Open Policy Agent) に基づいており、CustomResourceDefinitions (CRDs) を使用して policy を定義・適用します。Gatekeeper は AdmissionWebhook として動作し、cluster 内で作成または変更される resource が定義済み policy に準拠していることを検証します。これにより、security policy、resource limit、naming convention など、さまざまな policy を適用できます。
- ResourceQuota が適用された namespace で、resource request と limit を指定せずに pod を作成するとどうなりますか？
- A) pod はデフォルトの resource request と limit で作成される
- B) pod の作成が拒否される
- C) pod は作成されるが schedule されない
- D) pod は作成され、無制限の resource を使用できる
答えを表示
答え: B) pod の作成が拒否される
解説: ResourceQuota が namespace に適用され、CPU や memory などの computing resource に quota が設定されている場合、その namespace 内のすべての container は resource request と limit を明示的に指定する必要があります。指定しない場合、API server は pod 作成 request を拒否します。これは、quota が適用された namespace で resource 使用量を正確に追跡し制限するためです。
- Kubernetes における PriorityClass の主な目的は何ですか？
- A) pod scheduling priority を定義する
- B) namespace resource allocation priority を設定する
- C) API request processing priority を決定する
- D) node importance level を設定する
答えを表示
答え: A) pod scheduling priority を定義する
解説: PriorityClass は pod の scheduling priority を定義します。resource が不足している場合、priority の高い pod は priority の低い pod より先に schedule され、必要に応じて priority の低い pod を preempt できます。
短答問題
- ResourceQuota と LimitRange の主な違いを説明してください。
答えを表示
答え: ResourceQuota は namespace 全体の resource 使用量を制限する一方、LimitRange は namespace 内の個々の container または pod に対して resource 制約を設定します。
主な違い:
- Scope: ResourceQuota は namespace 全体に適用され、LimitRange は個々の resource（pod、container など）に適用されます。
- Purpose: ResourceQuota は namespace 全体の resource 使用量を制限する一方、LimitRange はデフォルト設定、最小/最大 limit などを通じて個々の resource 使用量を制御します。
- Enforcement: ResourceQuota が設定されている場合、quota を超える resource 作成は拒否されます。LimitRange は resource 作成時にデフォルトを適用するか、limit を超える場合に拒否します。
- Resource types: ResourceQuota は CPU や memory だけでなく、pod、service、PVC などの object 数も制限できます。LimitRange は主に CPU、memory、storage などの computing resource に焦点を当てます。
- Pod Security Standards の 3 つの policy level（Privileged、Baseline、Restricted）とその特徴を説明してください。
答えを表示
答え: Pod Security Standards は、pod security 設定のために 3 つの policy level を定義しています:
Privileged:
- ほとんど制限のない、最も open な policy。
- すべての privileged operation を許可します。
- host namespace、host port、privileged container などを使用できます。
- development や administrative work には適していますが、production では重大な security risk があります。
Baseline:
- 既知の privilege escalation 経路を防止する中間 level の policy。
- ほとんどの workload に適した baseline level の security を提供します。
- privileged container と host namespace の使用を制限します。
- ただし、一部の privileged operation（例: host path mount）はまだ許可されます。
Restricted:
- 強化された security 設定を持つ、最も制限の厳しい policy。
- least privilege の原則に従い、security best practice を強制します。
- privileged container、host namespace、host path mount、privilege escalation を禁止します。
- container を non-root user として実行することを強制します。
- security-critical な production workload に適しています。
- NetworkPolicy を使用して、特定の namespace 内の pod が別の namespace 内の特定の pod とだけ通信できるように制限する方法を説明してください。
答えを表示
答え: NetworkPolicy を使用して、特定の namespace 内の pod が別の namespace 内の特定の pod とだけ通信できるように制限するには:
- source namespace に NetworkPolicy を適用する:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-specific-communication
namespace: source-namespace # Source namespace
spec:
podSelector: {} # Apply to all pods
policyTypes:
- Egress
egress:
- to:
- namespaceSelector:
matchLabels:
name: destination-namespace # Destination namespace label
podSelector:
matchLabels:
app: specific-app # Destination pod label- destination namespace に NetworkPolicy を適用する:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-from-specific-namespace
namespace: destination-namespace # Destination namespace
spec:
podSelector:
matchLabels:
app: specific-app # Destination pod label
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
name: source-namespace # Source namespace labelこの方法が機能するには、namespace に適切な label が必要です:
kubectl label namespace source-namespace name=source-namespace
kubectl label namespace destination-namespace name=destination-namespaceNetworkPolicy はデフォルトで allow-list mode で動作するため、これらの policy が適用されると、明示的に許可された通信のみが可能になり、それ以外はすべてブロックされます。
- Kubernetes で OPA Gatekeeper を使用して実装できる policy の例を 3 つ説明してください。
答えを表示
答え: OPA Gatekeeper を使用して実装できる policy の例:
Image Registry Restriction:
- 承認済み registry からのみ image を pull することを強制する policy
- 例: company internal registry または特定の trusted public registry のみを許可
yamlapiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sAllowedRepos metadata: name: allowed-repos spec: match: kinds: - apiGroups: [""] kinds: ["Pod"] parameters: repos: - "docker.io/company/" - "gcr.io/trusted-project/"Enforce Resource Requests and Limits:
- すべての container に resource request と limit の設定を強制する policy
- resource exhaustion を防ぎ、適切な resource allocation を確保します
yamlapiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sRequiredResources metadata: name: container-must-have-limits-and-requests spec: match: kinds: - apiGroups: [""] kinds: ["Pod"] parameters: limits: - cpu - memory requests: - cpu - memoryPrevent Privileged Containers:
- privileged container の実行を禁止する policy
- security risk を低減し、container isolation を確保します
yamlapiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sPSPPrivilegedContainer metadata: name: prevent-privileged-containers spec: match: kinds: - apiGroups: [""] kinds: ["Pod"]
（上記のうち 3 つだけを説明すればよい）
- Kubernetes で PriorityClass を使用して重要な workload の可用性を確保する方法を説明してください。
答えを表示
答え: PriorityClass を使用して重要な workload の可用性を確保する方法:
PriorityClass を定義する:
- 重要度に基づいてさまざまな priority level の PriorityClass を作成します
yamlapiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: high-priority value: 1000000 # Higher value means higher priority globalDefault: false description: "This priority class should be used for critical production workloads."重要な workload に PriorityClass を割り当てる:
- 重要な pod に PriorityClass reference を追加します
yamlapiVersion: v1 kind: Pod metadata: name: critical-service spec: priorityClassName: high-priority containers: - name: app image: critical-service:latestPreemption を活用する:
- resource が不足している場合、priority の高い pod は priority の低い pod を preempt（evict）して schedule されることができます
- これにより、重要な workload が常に実行できるようになります
System Priority Classes を考慮する:
- Kubernetes は system-cluster-critical (2000000000) や system-node-critical (2000001000) などの system priority class を提供します
- user-defined priority class は通常、これらより低い値を使用するべきです
Priority Hierarchy を設計する:
- workload の重要度に基づいて複数の priority level を定義します
- 例: Production services (900000)、Internal tools (500000)、Development/Test (100000)
ハンズオン問題
- 次の要件を満たす ResourceQuota を作成してください:
- Namespace: team-a
- 最大 10 pods
- 最大 5 services
- 合計 CPU requests: 4 cores
- 合計 memory requests: 8Gi
答えを表示
答え:
apiVersion: v1
kind: ResourceQuota
metadata:
name: team-a-quota
namespace: team-a
spec:
hard:
pods: "10"
services: "5"
requests.cpu: "4"
requests.memory: 8Gi適用方法:
# Create namespace
kubectl create namespace team-a
# Apply ResourceQuota
kubectl apply -f team-a-quota.yamlResourceQuota status の確認:
kubectl describe resourcequota team-a-quota -n team-a- 次の要件を満たす LimitRange を作成してください:
- Namespace: team-b
- Container default request: CPU 100m, Memory 256Mi
- Container default limit: CPU 200m, Memory 512Mi
- Container maximum limit: CPU 1 core, Memory 2Gi
答えを表示
答え:
apiVersion: v1
kind: LimitRange
metadata:
name: team-b-limits
namespace: team-b
spec:
limits:
- default:
cpu: 200m
memory: 512Mi
defaultRequest:
cpu: 100m
memory: 256Mi
max:
cpu: "1"
memory: 2Gi
type: Container適用方法:
# Create namespace
kubectl create namespace team-b
# Apply LimitRange
kubectl apply -f team-b-limits.yamlLimitRange status の確認:
kubectl describe limitrange team-b-limits -n team-b- 次の要件を満たす NetworkPolicy を作成してください:
- Namespace: web
- app label が 'frontend' の pods は app label が 'backend' の pods とのみ通信できる
- Backend pods は port 8080 の通信のみを許可する
答えを表示
答え:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: frontend-to-backend-only
namespace: web
spec:
podSelector:
matchLabels:
app: frontend
policyTypes:
- Egress
egress:
- to:
- podSelector:
matchLabels:
app: backend
ports:
- protocol: TCP
port: 8080
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: backend-allow-frontend-only
namespace: web
spec:
podSelector:
matchLabels:
app: backend
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
app: frontend
ports:
- protocol: TCP
port: 8080適用方法:
# Create namespace
kubectl create namespace web
# Apply NetworkPolicy
kubectl apply -f web-network-policies.yamlNetworkPolicy status の確認:
kubectl describe networkpolicy -n web- 次の要件で PriorityClass とそれを使用する pod を作成してください:
- PriorityClass name: high-priority
- Priority value: 100000
- Description: "For critical production workloads"
- Pod name: critical-app
- Image: nginx
答えを表示
答え:
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
name: high-priority
value: 100000
globalDefault: false
description: "For critical production workloads"
---
apiVersion: v1
kind: Pod
metadata:
name: critical-app
spec:
priorityClassName: high-priority
containers:
- name: nginx
image: nginx適用方法:
kubectl apply -f high-priority-pod.yamlPriorityClass と pod status の確認:
kubectl get priorityclass high-priority
kubectl get pod critical-app- 次の Pod Security 設定を適用してください:
- Namespace: restricted-ns
- Mode: enforce
- Level: restricted
答えを表示
答え:
Kubernetes 1.25 以降では、namespace に label を追加することで Pod Security Standards を適用できます:
apiVersion: v1
kind: Namespace
metadata:
name: restricted-ns
labels:
pod-security.kubernetes.io/enforce: restricted
pod-security.kubernetes.io/audit: restricted
pod-security.kubernetes.io/warn: restricted適用方法:
kubectl apply -f restricted-namespace.yamlまたは、既存の namespace に label を追加します:
kubectl create namespace restricted-ns
kubectl label namespace restricted-ns \
pod-security.kubernetes.io/enforce=restricted \
pod-security.kubernetes.io/audit=restricted \
pod-security.kubernetes.io/warn=restricted高度なトピック
- Kubernetes における OPA Gatekeeper と Kyverno の違い、およびそれぞれの pros と cons を説明してください。
答えを表示
答え:
OPA Gatekeeper vs Kyverno 比較:
Architecture and Approach:
- OPA Gatekeeper: Open Policy Agent (OPA) に基づき、Rego policy language を使用します。ConstraintTemplate と Constraint という 2 つの CRD を使用して policy を定義します。
- Kyverno: 独自の policy engine を使用し、YAML/JSON-based の policy definition を提供します。単一の Policy CRD を使用して policy を定義します。
Policy Language:
- OPA Gatekeeper: Rego language を使用し、強力ですが learning curve が急です。
- Kyverno: Kubernetes resource に似た YAML syntax を使用して policy を定義するため、Kubernetes user にとってより馴染みがあります。
Features:
- OPA Gatekeeper:
- complex policy を表現するための強力な policy language
- external data に基づく decision のために data source を統合できる
- policy library と reusable template をサポート
- Kyverno:
- 組み込みの resource 作成、変更、検証機能
- image verification と modification 機能
- resource が作成されたときに他の resource を自動的に作成できる
- policy exception handling 機能
- OPA Gatekeeper:
Pros:
- OPA Gatekeeper:
- より成熟しており、広く採用されている
- complex policy expression により適している
- さまざまな use case に対する豊富な documentation と example
- OPA ecosystem を Kubernetes 以外でも使用可能
- Kyverno:
- 馴染みのある YAML syntax により learning curve が緩やか
- 別の policy language の学習が不要
- 組み込みの resource 作成・変更機能
- setup と configuration がより簡単
- OPA Gatekeeper:
Cons:
- OPA Gatekeeper:
- Rego language の学習が必要
- setup と configuration が複雑
- resource modification には追加 configuration が必要
- Kyverno:
- 相対的に成熟度が低い
- 非常に complex な policy expression には制限がある場合がある
- OPA と比較して performance が低い場合がある
- OPA Gatekeeper:
Selection Criteria:
- Choose OPA Gatekeeper when:
- complex policy logic が必要
- すでに OPA を使用している、または Rego に慣れている
- さまざまな system 全体で一貫した policy application が必要
- Choose Kyverno when:
- quick start と容易な learning curve が重要
- team が Kubernetes resource syntax に慣れている
- resource 作成・変更機能が必要
- simple policy のみが必要
- Choose OPA Gatekeeper when:
- Kubernetes における Pod Security Admission と以前の PodSecurityPolicy (PSP) の主な違いを説明してください。
答えを表示
答え:
Pod Security Admission vs PodSecurityPolicy (PSP) 比較:
Implementation:
- PodSecurityPolicy: API resource（CRD）として実装され、admission controller を通じて適用されます。
- Pod Security Admission: 組み込みの admission controller として実装され、namespace label を通じて構成されます。
Configuration Method:
- PodSecurityPolicy: Cluster admin は PSP resource を作成し、RBAC を通じて user/service account に bind する必要があります。
- Pod Security Admission: enforcement level（enforce、audit、warn）と policy level（privileged、baseline、restricted）を指定する label を namespace に追加して適用します。
Policy Granularity:
- PodSecurityPolicy: 非常に細かい制御が可能で、さまざまな security context 設定を個別に構成できます。
- Pod Security Admission: 事前定義された 3 つの policy level（privileged、baseline、restricted）のみを提供し、詳細な設定を個別に調整することはできません。
Ease of Use:
- PodSecurityPolicy: RBAC binding が必要な複雑な setup で、configuration error がよく発生します。
- Pod Security Admission: simple な namespace labeling で適用でき、はるかに使いやすいです。
Scope:
- PodSecurityPolicy: cluster 全体または特定の user/service account に適用されます。
- Pod Security Admission: namespace ごとに適用されます。
Modes:
- PodSecurityPolicy: 適用するかしないかの binary approach。
- Pod Security Admission: 段階的な適用のために 3 つの mode（enforce、audit、warn）を提供します。
- enforce: violation がある場合、pod 作成を拒否
- audit: violation を audit log に記録
- warn: violation がある場合、warning message を表示
Migration and Support:
- PodSecurityPolicy: Kubernetes v1.25 で削除されました。
- Pod Security Admission: Kubernetes v1.23 から beta として利用可能で、v1.25 で PSP を完全に置き換えました。
Extensibility:
- PodSecurityPolicy: custom setting による高い extensibility。
- Pod Security Admission: extensibility は限定的で、より細かい制御には OPA Gatekeeper や Kyverno などの追加 tool が必要になる場合があります。