建设银行网站总是崩溃,个人网站备案名字不同,郑州妇科,常见的网络营销工具有哪些目录
一、Kubernetes API访问控制
1.传输安全(Transport Security)
2.认证(Authentication)
2.1 认证方式
2.2 ServiceAccount和普通用户的区别
2.3 ServiceAccount管理方式
自动ServiceAccount示例
手动ServiceAccount示例 3.鉴权 (Authorization)
3.1鉴权方式
3.2 …
目录
一、Kubernetes API访问控制
1.传输安全(Transport Security)
2.认证(Authentication)
2.1 认证方式
2.2 ServiceAccount和普通用户的区别
2.3 ServiceAccount管理方式
自动ServiceAccount示例
手动ServiceAccount示例 3.鉴权 (Authorization)
3.1鉴权方式
3.2 RBAC
4.准入控制 (Admission Control)
PodSecurity
安全级别 安全实施
配置示例
二、审计 (Auditing)
审计架构
审计策略Audit Policy
审计级别
审计策略文件示例
审计日志的存储Audit Sink
审计事件结构
三、Secret
四、网络策略NetworkPolicy)
网络策略的作用
网络策略的工作原理
网络策略示例 KubernetesK8s是一个强大的容器编排平台安全性至关重要。Kubernetes的安全机制可以分为多个层次包括集群层、网络层、应用层等。以下是Kubernetes中主要的安全机制Kubernetes API访问控制、Secret、网络策略NetworkPolicy) 、审计日志等等。
一、Kubernetes API访问控制 Kubernetes API访问控制是一组机制确保只有经过授权的用户或服务可以访问和操作集群资源。它涵盖了多个层面包括传输安全、认证、鉴权、准入控制和审计。以下是这些概念的详细介绍。 1.传输安全(Transport Security)
Kubernetes默认使用HTTPS来确保API通信的安全性防止数据在传输过程中被窃取或篡改。API服务器会使用TLS传输层安全协议对请求进行加密
客户端与服务器间通信加密通过使用TLS证书来验证服务器和客户端的身份从而加密通信。
Kubernetes API server的证书管理需要为Kubernetes集群中的API服务器配置正确的证书包括根证书和客户端证书。
保护内部组件的通信比如etcd的通信需要加密并使用适当的证书。
2.认证(Authentication)
2.1 认证方式 所有Kubernetes集群都有两类用户由Kubernetes管理的服务账户ServiceAccount、普通用户。所有API请求都需要经过身份认证以确保请求来自合法用户或服务并授予适当的权限。Kubernetes支持多种认证方式其中比较常见的是基于令牌的身份验证、x509证书、OpenID ConnectOIDC、服务账户ServiceAccount等。
x509证书用户通过x509证书与API服务器进行通信。这种方式通常用于Kubernetes管理员、集群节点和集群内的一些服务。例如客户端使用带有用户身份的证书通过kubectl命令访问API服务器。
Bearer TokenKubernetes使用令牌Token进行身份验证客户端可以通过将Bearer Token附加到HTTP请求中进行身份验证。
OIDC(OpenID Connect)通过外部身份提供者如Google、AWS、Keycloak等验证用户身份。OIDC是一种基于OAuth2.0协议的身份验证协议适合于与外部认证服务集成。
服务账户ServiceAccount服务账户用于集群内的应用程序或Pod来访问API服务器通常与RBAC基于角色的访问控制结合使用。 可以指定多个认证模块在这种情况下服务器依次尝试每个验证模块直到其中一个成功。
2.2 ServiceAccount和普通用户的区别 普通用户通常是指通过kubeconfig文件、证书或OIDC等方式认证的用户通常是Kubernetes集群的管理员或开发者Kubernetes不会直接在集群中创建或管理普通用户。 普通用户使用场景普通用户用于手动管理集群资源例如 kubectl 命令行工具或访问Kubernetes API。 ServiceAccount是Kubernetes中的一种特殊类型的账户用于赋予Pod在集群中运行时的身份。它主要用于集群内的自动化服务而不是手动用户操作。 ServiceAccount使用场景ServiceAccount常用于需要与API服务器交互的应用程序或用于Pod自动管理集群资源。例如CI/CD工具、监控工具、控制器等。
2.3 ServiceAccount管理方式 每个ServiceAccount都与一个JSON Web Token (JWT) 关联该令牌存储在Pod的文件系统中位于 /var/run/secrets/kubernetes.io/serviceaccount/token路径下。Pod启动后会使用这个令牌与Kubernetes API服务器进行通信API服务器根据该令牌进行身份验证。ServiceAccount通常与RBAC结合授予Pod访问某些API资源的权限。 ServiceAccount可以通过自动或手动方式使用。默认情况下每个命名空间Namespace都有一个默认的ServiceAccountPod启动时会自动关联这个ServiceAccount。如果需要更高的权限或特殊用途我们也可以手动创建并指定ServiceAccount。
自动ServiceAccount示例 创建及查看Pod #创建Pod kubectl run my-pod --imagenginx #查看Pod的ServiceAccount kubectl get pod my-pod -o yaml 在输出中会看到以下部分表示该Pod使用了default ServiceAccount serviceAccount: default serviceAccountName: default 查看ServiceAccount令牌: kubectl exec -it my-pod -- cat /var/run/secrets/kubernetes.io/serviceaccount/token 手动ServiceAccount示例 创建ServiceAccount #手动创建一个新的ServiceAccount kubectl create serviceaccount my-service-account #查看ServiceAccount的详细信息 kubectl get serviceaccount my-service-account -o yaml 创建Pod并绑定自定义的ServiceAccount
apiVersion: v1
kind: Pod
metadata:name: my-pod-with-sa
spec:serviceAccountName: my-service-account # 指定使用的ServiceAccountcontainers:- name: my-containerimage: nginx验证Pod是否绑定了自定义ServiceAccount #创建Pod kubectl apply -f pod-with-sa.yaml #查看该 Pod 的详细信息 kubectl get pod my-pod-with-sa -o yaml 输出中会显示 serviceAccount: my-service-account serviceAccountName: my-service-account 为ServiceAccount配置权限可选: #授予my-service-account读取Pod信息的权限。 kubectl create role my-role --verbget,list,watch --resourcepods kubectl create rolebinding my-role-binding --rolemy-role --serviceaccountdefault:my-service-account ServiceAccount 默认没有太多权限可以使用Role和RoleBinding为它配置权限。 关于权限在鉴权 (Authorization)部分说明。 3.鉴权 (Authorization)
3.1鉴权方式 在认证之后Kubernetes会决定认证通过的用户是否有权限执行特定操作。Kubernetes使用多种授权方式来控制API请求的访问权限。
RBAC (基于角色的访问控制)基于预定义的角色来授予用户或组的权限通过Role和ClusterRole结合RoleBinding和ClusterRoleBinding来实施访问控制。
ABAC (基于属性的访问控制)通过指定策略文件根据请求的属性如用户名、资源类型、动作决定是否授权。
Webhook模式将鉴权请求转发到外部服务处理适合实现自定义的访问控制逻辑。
3.2 RBAC RBACRole-Based Access Control基于角色的访问控制是Kubernetes中的一种访问控制机制用于定义用户或服务账号对 Kubernetes 资源的访问权限。通过 RBAC集群管理员可以根据角色分配权限并通过绑定这些角色给用户、组或ServiceAccount来控制访问权限。 RBAC 主要由四个核心组件构成
Role定义某个特定Namespace下的权限。它包含了对资源例如Pods、Services等的操作规则如get、create、delete等。ClusterRole定义集群范围的权限可以在所有Namespace中使用或直接应用于集群级资源如节点、PersistentVolumes等。RoleBinding将Role绑定到用户、组或ServiceAccount使其在指定的Namespace中拥有相应的权限。ClusterRoleBinding将ClusterRole绑定到用户、组或ServiceAccount使其在整个集群中拥有相应的权限。 Role RoleBinding示例
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:namespace: default #作用范围是default命名空间name: pod-reader
rules:
- apiGroups: [] #空字符串表示核心API组resources: [pods]verbs: [get, list, watch] #授予的操作权限apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:name: read-podsnamespace: default
subjects: #绑定的用户或服务账户
- kind: User #可以是User、Group或ServiceAccountname: example-user #用户名apiGroup: rbac.authorization.k8s.io
roleRef:kind: Role #绑定的角色类型name: pod-reader #绑定的角色名称apiGroup: rbac.authorization.k8s.ioexample-user现在拥有default命名空间中读取pods资源的权限。 ClusterRole ClusterRoleBinding示例
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:name: cluster-pod-reader
rules:
- apiGroups: [] # 核心API组resources: [pods]verbs: [get, list, watch]apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:name: read-pods-clusterwide
subjects: #绑定的用户或服务账户
- kind: Username: example-user #用户名apiGroup: rbac.authorization.k8s.io
roleRef:kind: ClusterRole #绑定ClusterRolename: cluster-pod-reader #绑定的角色名称apiGroup: rbac.authorization.k8s.ioci-service-account现在可以读取集群中所有命名空间的Pod信息。
4.准入控制 (Admission Control) 准入控制是对经过认证和授权的API请求进行进一步的检查和修改的一个步骤。在请求进入Kubernetes API Server之前准入控制器可以阻止请求或修改对象。推荐使用的准入控制器默认情况下都处于启用状态。可以使用--enable-admission-plugins来启用默认设置以外的其他准入控制器。 常见的内置准入控制器例如NamespaceLifecycle、LimitRanger、PodSecurity、RuntimeClass等用于特定的访问和资源管理。以下介绍PodSecurity概念
PodSecurity Pod 安全性标准Pod Security StandardsPSS是Kubernetes提供的一套安全标准用于定义和管理Pod 的安全策略。通过使用Pod安全性标准Kubernetes集群管理员可以控制和限制 Pod在运行时的行为从而提高集群的整体安全性。这套标准是通过Kubernetes的内置准入控制器PodSecurity来实现的。 默认情况下Kubernetes不启用PodSecurity因此没有默认的安全级别和模式。如果启用PodSecurity准入控制器默认的安全级别和模式需要手动配置。
安全级别 Pod 安全性标准主要定义了三个安全级别或模式 特权级别Privileged 用途最宽松的安全级别允许Pod以完全特权运行。适用于那些需要完全控制底层主机的Pod例如需要执行主机级别操作的系统组件或Pod。特点 允许使用特权模式、HostPath挂载、特权容器、HostNetwork等功能。几乎没有安全约束风险较高。 基线级别Baseline 用途旨在允许大多数应用程序正常运行同时施加基本的安全限制。适合一般的应用程序。特点 拒绝特权模式和特权容器。限制HostPath挂载防止容器访问主机的敏感文件。限制某些Linux特性如CAP_SYS_ADMIN等高危特权。禁止使用HostNetwork和HostPID。 受限级别Restricted 用途最严格的安全级别施加了所有可用的最佳安全实践。适用于高度敏感的应用程序需要严格限制Pod的行为。特点 禁止一切特权操作包括HostPath挂载、特权容器、HostNetwork、HostPID、HostIPC等。强制限制容器的用户权限如不能以root用户身份运行容器。强制限制进程和文件系统的权限最大限度减少攻击面。 安全实施 Pod 安全性标准的实施分为以下几种操作模式
Enforce执行强制执行指定的安全策略如果Pod不符合要求则禁止其创建或更新。Audit审计记录违反安全策略的操作但不阻止Pod创建或更新。Warn警告向用户发出警告通知其违反了安全策略但不阻止Pod创建或更新。 这些模式允许管理员以递进方式加强安全控制逐步引导开发人员适应更严格的安全标准。
配置示例
apiVersion: v1
kind: Namespace
metadata:name: restricted-namespacelabels:pod-security.kubernetes.io/enforce: restricted #强制执行受限级别pod-security.kubernetes.io/audit: baseline #审计基线级别pod-security.kubernetes.io/warn: baseline #警告基线级别在这个示例中restricted-namespace命名空间中强制执行受限级别的Pod安全策略并在审计和警告模式下评估基线级别的策略。
apiVersion: v1
kind: Namespace
metadata:name: baseline-namespacelabels:pod-security.kubernetes.io/enforce: baseline #强制执行基线级别在这个示例中baseline-namespace命名空间中所有创建的Pod必须符合基线级别的安全标准否则创建或更新请求将被拒绝。
二、审计 (Auditing) Kubernetes 审计日志会记录API服务器处理的每一个HTTP请求它包括从请求的接收到最终的处理结果允许或拒绝以及返回的响应。审计的事件按照发生的顺序记录下来管理员可以根据这些日志了解集群的操作情况。 Kubernetes 默认没有开启审计需要在kube-apiserver的配置文件中启用审计功能并手动配置审计策略文件。API 服务器不默认生成审计日志也没有预设的审计级别。
审计架构
审计系统由三个主要组件组成
Audit Policy定义审计事件的记录规则如记录哪些操作、哪些用户的行为等。Audit Sink审计日志的存储位置可以是文件、标准输出或通过HTTP Webhook发送到外部服务。Audit Event每个 API 请求会被记录为一个审计事件包含详细的上下文信息。
审计策略Audit Policy 审计策略通过一个策略文件来定义策略文件控制什么样的API请求会被记录以及记录的详细程度。
审计级别 每个请求可以按不同的审计级别记录
None不记录任何内容。Metadata仅记录请求的元数据如用户、操作、时间等不记录请求和响应的内容。Request记录请求的元数据以及请求体但不记录响应体。RequestResponse记录请求的元数据、请求体和响应体包含了所有详细信息。
审计策略文件示例 一个典型的审计策略文件会定义不同资源、不同用户和操作的记录级别。下面是一个示例策略文件 apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: RequestResponse # 对于所有的pod操作记录请求和响应resources:- group: resources: [pods]
- level: Metadata #对于所有的secrets操作记录元数据resources:- group: resources: [secrets]
- level: None #忽略对serviceaccounts的请求resources:- group: resources: [serviceaccounts]
- level: Request #记录所有的请求操作和元数据users: [system:serviceaccount:kube-system:default]verbs: [create, update, patch]
- level: Metadata #默认记录所有其他请求的元数据omitStages:- RequestReceived这个策略文件的规则说明如下
对于所有的Pod操作记录详细的请求和响应。对于 Secret 操作仅记录元数据例如操作的时间、用户。忽略ServiceAccount的所有操作。对特定的服务账户的create、update、patch请求记录请求的详细信息。对所有其他请求默认记录元数据。
审计日志的存储Audit Sink Kubernetes 支持多种审计日志的输出方式通常包括
文件输出将审计日志写入文件。Webhook 输出通过HTTP POST请求将审计日志发送到外部服务。 文件输出是一种常见的方式API服务器可以将审计日志写入到指定文件。 启动kube-apiserver时可以通过以下参数配置文件输出、 kube-apiserver \ --audit-policy-file/etc/kubernetes/audit-policy.yaml \ --audit-log-path/var/log/kubernetes/audit.log \ --audit-log-maxage30 \ --audit-log-maxbackup10 \ --audit-log-maxsize100 --audit-policy-file指定审计策略文件路径。--audit-log-path审计日志文件的存储路径。--audit-log-maxage日志文件保存的最大天数。--audit-log-maxbackup保留的旧审计日志文件的最大数量。--audit-log-maxsize每个日志文件的最大大小以 MB 为单位。
审计事件结构 审计日志中的每个事件都包含丰富的上下文信息在下面的输出示例中requestObject和 responseObject分别记录了请求和响应的详细内容
{kind: Event,apiVersion: audit.k8s.io/v1,level: RequestResponse,stage: ResponseComplete,requestURI: /api/v1/namespaces/default/pods,verb: create,user: {username: admin,groups: [system:masters]},sourceIPs: [192.168.1.100],objectRef: {resource: pods,namespace: default,name: my-pod},responseStatus: {metadata: {},code: 201},requestObject: {kind: Pod,metadata: {name: my-pod},spec: {containers: [{name: nginx,image: nginx:latest}]}},responseObject: {kind: Pod,metadata: {name: my-pod},spec: {containers: [{name: nginx,image: nginx:latest}]}}
}三、Secret Secret API为需要保密的配置值提供基本保护。可以回顾 Kubernetes从零到精通13-Configmap、Secret
四、网络策略NetworkPolicy) Kubernetes 中的网络策略NetworkPolicy 是一种控制Pod间流量和Pod与外部网络流量的安全机制。它允许用户定义哪些流量可以进入和离开Pod以确保集群的安全性。 网络策略仅会在支持网络策略的网络插件CNI如 Calico中生效。Kubernetes 默认的网络实现不支持网络策略。网络插件可以回顾Kubernetes从零到精通11-CNI网络插件。
网络策略的作用 NetworkPolicy是通过定义一组规则来允许或拒绝指定Pod的网络流量。这些规则可以基于
命名空间限制特定命名空间中的 Pod 间的流量。Pod 标签限制带有特定标签的 Pod 间的流量。IP Block限制特定的 IP 地址段的流量。
网络策略的工作原理 Kubernetes 网络策略主要用来定义
入口流量Ingress进入Pod的流量。出口流量Egress从Pod发送出的流量。
没有配置网络策略时所有Pod之间的网络流量默认是允许的一旦定义了网络策略只有符合规则的流量才会被允许。
网络策略的基本结构 一个网络策略通过以下几部分定义
Pod选择器选择哪些 Pod 应该应用这条策略。策略类型Ingress不是Ingress、Gateway api只是名称相同或Egress指定策略是控制入口流量还是出口流量。规则指定允许哪些流量通过规则可以基于Pod标签、IP 地址块、命名空间等定义。
网络策略示例 下面的网络策略将阻止所有流向my-pod的流量除了带有特定标签的Pod发送的流量
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:name: allow-specific-podsnamespace: default
spec:podSelector:matchLabels:app: my-pod #应用此策略的PodpolicyTypes:- Ingress #定义入口流量规则ingress:- from:- podSelector:matchLabels:app: allowed-app #允许带有此标签的Pod发送流量该策略允许来自特定IP地址段如192.168.0.0/16的流量其他流量会被拒绝
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:name: allow-from-ip-rangenamespace: default
spec:podSelector:matchLabels:app: my-pod #应用此策略的PodpolicyTypes:- Ingressingress:- from:- ipBlock:cidr: 192.168.0.0/16 #允许的IP地址范围下面的网络策略允许Pod访问外部网络注意这里只是在策略上允许访问外部网络底层网络能不能支持该Pod访问外部网络需要看具体网络情况但限制对特定命名空间内其他 Pod 的访问
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:name: allow-egressnamespace: default
spec:podSelector:matchLabels:app: my-apppolicyTypes:- Egress #定义出口流量规则egress:- to:- ipBlock:cidr: 0.0.0.0/0 #允许Pod访问外部网络该策略将完全隔离某个Pod的网络流量既不允许它接收流量也不允许它发送流量
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:name: deny-allnamespace: default
spec:podSelector:matchLabels:app: isolated-pod #目标PodpolicyTypes:- Ingress #不允许任何流量进入- Egress #不允许任何流量离开
