rainit2006
commented
1 month ago K8S Security
https://kubernetes.io/docs/concepts/security/
Pod Security Standards
Pod Security Admissionは、Kubernetes v1.25でGA (General Availability)となったビルトインのポリシ制御機能で、Pod Security Policyの後継機能に該当します。Pod Security AdmissionはPod Security Standardsに準拠した3種類のポリシ(表2)と3種類のモード（表3）を組み合わせてnamespace(Kubernetesにおけるリソースのグループ単位)に紐づけることで適用します。
Pod Security Standards https://kubernetes.io/docs/concepts/security/pod-security-standards/ The Pod Security Standards define three different policies to broadly cover the security spectrum. These policies are cumulative and range from highly-permissive to highly-restrictive. This guide outlines the requirements of each policy.
| Profile | Description |
|---|---|
| Privileged | Unrestricted policy, providing the widest possible level of permissions. This policy allows for known privilege escalations. |
| Baseline | Minimally restrictive policy which prevents known privilege escalations. Allows the default (minimally specified) Pod configuration. |
| Restricted | Heavily restricted policy, following current Pod hardening best practices. |
PodSecurityPolicy （removed！）
Note： PodSecurityPolicy was deprecated in Kubernetes v1.21, and removed from Kubernetes in v1.25.
Pod Security Admission
https://kubernetes.io/docs/concepts/security/pod-security-admission/ Kubernetes offers a built-in Pod Security admission controller to enforce the Pod Security Standards. Pod security restrictions are applied at the namespace level when pods are created.
Pod Security Admission labels for namespaces
| Once the feature is enabled or the webhook is installed, you can configure namespaces to define the admission control mode you want to use for pod security in each namespace. Kubernetes defines a set of labels that you can set to define which of the predefined Pod Security Standard levels you want to use for a namespace. The label you select defines what action the control plane takes if a potential violation is detected: Mode | Description |
|---|---|
| enforce | Policy violations will cause the pod to be rejected. |
| audit | Policy violations will trigger the addition of an audit annotation to the event recorded in the audit log, but are otherwise allowed. |
| warn | Policy violations will trigger a user-facing warning, but are otherwise allowed. |
例として、図4のルールを適用した場合、下記のような挙動になります。
Baselineポリシに違反するPodのデプロイを禁止する Restrictedポリシに違反するPodのデプロイを検知した場合はAudit Logに記録する Restrictedポリシに違反するPodのデプロイを検知した場合は警告を表示する
apiVersion: v1
kind: Namespace
metadata:
name: namespace-sample
labels:
pod-security.kubernetes.io/enforce: baseline
pod-security.kubernetes.io/audit: restricted
pod-security.kubernetes.io/warn: restrictedPod Security Policy やPod Security AdmissionはKubernetesのビルトイン機能ですが、同様のサードパーティツールとしてOPA Gatekeepernew window[3]、Kyvernonew window[4] 、jsPolicynew window[5]なども開発されています。ここでは、OPA GatekeeperをPod Security Admissionの比較対象として取り上げます。
OPA Gatekeeperは、Kubernetesで取り扱われるリソース定義ファイルに対する検査が可能なポリシ制御ツールです。ポリシはRego言語で記述されるため、Regoに馴染みのない人にとっては導入には一定の学習コストが生じますが、namespaceやpodなどの様々なリソースのパラメータを検査・ブロックすることが可能になります。特に、Podに関するポリシは豊富な設定テンプレート（Gatekeeper Library）が用意されているため、導入が容易かつ柔軟なポリシ設定が行えます。
Reference：https://jpn.nec.com/cybersecurity/blog/221209/index.html
architecture
https://kubernetes.io/docs/concepts/architecture/
etcd
Consistent and highly-available key value store used as Kubernetes' backing store for all cluster data. If your Kubernetes cluster uses etcd as its backing store, make sure you have a back up plan for the data.
Kubernetes Master控制组件，调度管理整个系统（集群），包含如下组件：
简述Kubernetes ingress
Kubernetes的Ingress资源对象，用于将不同URL的访问请求转发到后端不同的Service，以实现HTTP层的业务路由机制。
Kubernetes使用了Ingress策略和Ingress Controller，两者结合并实现了一个完整的Ingress负载均衡器。使用Ingress进行负载分发时，Ingress Controller基于Ingress规则将客户端请求直接转发到Service对应的后端Endpoint（Pod）上，从而跳过kube-proxy的转发功能，kube-proxy不再起作用，全过程为：ingress controller + ingress 规则 ----> services。
同时当Ingress Controller提供的是对外服务，则实际上实现的是边缘路由器的功能。
简述Kubernetes各模块如何与API Server通信
Kubernetes API Server作为集群的核心，负责集群各功能模块之间的通信。集群内的各个功能模块通过API Server将信息存入etcd，当需要获取和操作这些数据时，则通过API Server提供的REST接口（用GET、LIST或WATCH方法）来实现，从而实现各模块之间的信息交互。
如kubelet进程与API Server的交互：每个Node上的kubelet每隔一个时间周期，就会调用一次API Server的REST接口报告自身状态，API Server在接收到这些信息后，会将节点状态信息更新到etcd中。
如kube-controller-manager进程与API Server的交互：kube-controller-manager中的Node Controller模块通过API Server提供的Watch接口实时监控Node的信息，并做相应处理。 如kube-scheduler进程与API Server的交互：Scheduler通过API Server的Watch接口监听到新建Pod副本的信息后，会检索所有符合该Pod要求的Node列表，开始执行Pod调度逻辑，在调度成功后将Pod绑定到目标节点上。
简述Kubernetes kubelet的作用
在Kubernetes集群中，在每个Node（又称Worker）上都会启动一个kubelet服务进程。该进程用于处理Master下发到本节点的任务，管理Pod及Pod中的容器。每个kubelet进程都会在API Server上注册节点自身的信息，定期向Master汇报节点资源的使用情况，并通过cAdvisor监控容器和节点资源。
简述Kubernetes Secret作用
Secret对象，主要作用是保管私密数据，比如密码、OAuth Tokens、SSH Keys等信息。将这些私密信息放在Secret对象中比直接放在Pod或Docker Image中更安全，也更便于使用和分发。