先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新网络安全全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上网络安全知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip204888 （备注网络安全）

正文

所有请求都要经过apiserver，这里进行身份认证，只认准正确的账号

（2）Authorization

账号认证通过后进行资源权限判定，授权发生在认证成功之后，这时候就知道请求用户是谁， Kubernetes就会根据事先定义的授权策略来决定用户是否有权限访问。请求报文一般包含这些内容，请求的用户、请求的路径、请求的动作等，kubernetes将这些内容与事先定义好的策略比对，如果符合策略，则认为授权通过，否则会错误。

（3）Admission Control

准入控制，实现更加精细的访问控制

二.授权管理介绍

我是以kubeadm安装的kubernetes，主要是用到rbac的角色访问控制。

实际上apiserver支持至少六种授权策略：

1.AlwaysDeny

表示拒绝所有请求，通常不使用哈

2.AlwaysAllow

默认的策略，允许接收所有请求，就相当于没进行权限控制

3.ABAC

表示使用用户配置的授权规则对用户请求进行匹配和控制（基于用户属性）

4.Webhook

引用外部REST服务对用户进行授权管理

5.Node

用于对kubelet发出的请求进行访问控制，比较特殊的一种模式

6.RBAC

基于角色访问控制，一般是需要账号等

三.Role解释

理解为哪些对象拥有哪些权限，如下介绍RBAC的四个顶级资源对象（Role、Rolebinding、ClusterRole、ClusterRoleBinding）

1.Role和ClusterRole

角色，可以为角色指定一组权限，指定什么权限该角色就拥有什么权限，一个角色一组权限

（1）Role，是对指定的命名空间的资源进行权限配置，是需要指定名称空间的

#rule中的参数用来对授权进行配置
rules:
- apiGroups: [""]  #支持的API组列表,"" 空字符串，表示核心API群
  resources: ["pods"]  #支持的资源对象列表
  verbs: ["get", "watch", "list"]  #允许的对资源对象的操作方法列表

（2）ClusterRole，是对整个集群范围内资源（不仅仅限于具体某个名称空间）、非资源类型等进行授权配置

2.Rolebinding和ClusterBinding

角色绑定，将角色绑定给目标对象，那么目标对象就会拥有该角色的权限

（1）Rolebinding，是将Role和目标对象进行绑定，可以是User、Group和ServiceAccount

# RoleBinding可以将同一namespace中的subject绑定到某个Role下，subject内的对象就会拥有role的权限
​
subjects:
- kind: User
  name: username
apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: 定义的的role的名称
  apiGroup: rbac.authorization.k8s.io

（2）ClusterRoleBinding，ClusterRoleBinding在整个集群级别的特定的subject与ClusterRole绑定，授予subject内目标权限，用法和Rolebinding一致

3.Rolebinding和ClusterRole

（1）可以将ClusterRole把通过RoleBinding绑定给目标对象，但是由于此时是使用Rolebinding方式，所以ClusterRole此时的作用范围也被局限在特定的namespace中。

（2）集群管理员会在集群范围内预先定义一组通用的角色（ClusterRole），然后在多个命名空间中重复使用这些 ClusterRole，好处是：

通过预定义一组通用的 ClusterRole，可以避免在每个命名空间中都重新定义相同的权限规则，从而节省时间和精力。

使用相同的 ClusterRole 在不同的命名空间中授权，可以确保各个命名空间下的基础授权规则保持一致，简化了权限管理并提供一致的用户体验。

当需要更新权限规则时，只需修改预定义的 ClusterRole，所有引用该 ClusterRole 的 RoleBinding 将自动应用新的权限规则，避免了在每个命名空间中手动更新权限规则的繁琐过程。

四.准入控制

用户的权限请求时要通过准入控制后最后才会被apiserver去判断是否处理，通过则继续处理，否则驳回请求

1.命令格式

--admission-control=配置的控制器列表，多个参数用“,”隔开

2.可配置控制器

参数	含义
AlwaysAdmit	允许所有请求
AlwaysDeny	禁止所有请求，通常不用哈
AlwaysPullImages	在启动容器之前总去下载镜像
DenyExecOnPrivileged	拦截所有想在Privileged Container上执行命令的请求
ImagePolicyWebhook	一个插件，将允许后端的一个Webhook程序来完成admission controller的功能
Service Account	实现ServiceAccount，自动化
SecurityContextDeny	一个插件，将使用SecurityContext的Pod中的定义全部失效
ResourceQuota	用于资源配额管理，观察所有请求，确保在namespace上的配额不会超标
LimitRanger	用于资源限制管理，作用于namespace上，确保对Pod进行资源限制
InitialResources	为未设置资源请求与限制的Pod，根据其镜像的历史资源的使用情况进行设置
NamespaceLifecycle	如果尝试在一个不存在的namespace中创建资源对象，则该创建请求将被拒绝。当删除一个namespace时，系统将会删除该namespace中所有对象。
DefaultStorageClass	为了实现共享存储的动态供应，为未指定StorageClass或PV的PVC尝试匹配默认的StorageClass，尽可能减少用户在申请PVC时所需了解的后端存储细节
DefaultTolerationSeconds	一个插件，为那些没有设置forgiveness tolerations并具有notready:NoExecute和unreachable:NoExecute两种taints的Pod设置默认的“容忍”时间，为5min
PodSecurityPolicy	一个插件，用于在创建或修改Pod时决定是否根据Pod的security context和可用的PodSecurityPolicy对Pod的安全策略进行控制

五.例子

配置一个sulibao用户，限制其只能对ns-sulibao名称空间内的pod进行get, watch, list三个行为

1.生成签署证书

[root@k8s-master ~]# cd /etc/kubernetes/pki/
[root@k8s-master pki]# (umask 077; openssl genrsa -out sulibao.key 2048)    #生成.key，在当前生效
Generating RSA private key, 2048 bit long modulus
............................+++
...........................................................+++
e is 65537 (0x10001)
[root@k8s-master pki]# openssl req -new -key sulibao.key -out sulibao.csr -subj "/CN=sulibao/O=sulibao"
#生成.csr，用sulibao用户和组进行签署
[root@k8s-master pki]# ll
total 64
-rw-r--r-- 1 root root 1285 Mar  9 11:24 apiserver.crt
-rw-r--r-- 1 root root 1155 Mar  9 11:24 apiserver-etcd-client.crt
-rw------- 1 root root 1679 Mar  9 11:24 apiserver-etcd-client.key
-rw------- 1 root root 1679 Mar  9 11:24 apiserver.key
-rw-r--r-- 1 root root 1164 Mar  9 11:24 apiserver-kubelet-client.crt
-rw------- 1 root root 1675 Mar  9 11:24 apiserver-kubelet-client.key
-rw-r--r-- 1 root root 1107 Mar  9 11:24 ca.crt
-rw------- 1 root root 1675 Mar  9 11:24 ca.key
drwxr-xr-x 2 root root  162 Mar  9 11:24 etcd
-rw-r--r-- 1 root root 1123 Mar  9 11:24 front-proxy-ca.crt
-rw------- 1 root root 1679 Mar  9 11:24 front-proxy-ca.key
-rw-r--r-- 1 root root 1119 Mar  9 11:24 front-proxy-client.crt
-rw------- 1 root root 1675 Mar  9 11:24 front-proxy-client.key
-rw------- 1 root root 1679 Mar  9 11:24 sa.key
-rw------- 1 root root  451 Mar  9 11:24 sa.pub
-rw-r--r-- 1 root root  911 Mar  9 19:32 sulibao.csr
-rw------- 1 root root 1679 Mar  9 19:31 sulibao.key
#用apiserver证书签署
[root@k8s-master pki]# openssl x509 -req -in sulibao.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out sulibao.csr -days 3650
#生成
Signature ok
subject=/CN=sulibao/O=sulibao
Getting CA Private Key
[root@k8s-master pki]# kubectl config set-cluster kubernetes --embed-certs=true --certificate-authority=/etc/kubernetes/pki/ca.crt --server=https://192.168.2.150:6443
Cluster "kubernetes" set.

2.设置用户和上下文信息

[root@k8s-master pki]# kubectl config set-credentials sulibao --embed-certs=true --client-certificate=/etc/kubernetes/pki/sulibao.csr --client-key=/etc/kubernetes/pki/sulibao.key 
User "sulibao" set.
​
[root@k8s-master pki]# kubectl config set-context sulibao@kubernetes --cluster=kubernetes --user=sulibao
Context "sulibao@kubernetes" created.
​
[root@k8s-master pki]# kubectl config use-context sulibao@kubernetes
Switched to context "sulibao@kubernetes".
#当前无权限
[root@k8s-master pki]# kubectl get pods -n ns-sulibao
Error from server (Forbidden): pods is forbidden: User "sulibao" cannot list resource "pods" in API group "" in the namespace "ns-sulibao"
​
[root@k8s-master pki]# kubectl config use-context kubernetes-admin@kubernetes 
Switched to context "kubernetes-admin@kubernetes".

3.为sulibao用户授权

[root@k8s-master pki]# vim role.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: ns-sulibao
​
---
​
apiVersion: rbac.authorization.k8s.io/v1


### 给大家的福利


**零基础入门**


对于从来没有接触过网络安全的同学，我们帮你准备了详细的学习成长路线图。可以说是最科学最系统的学习路线，大家跟着这个大的方向学习准没问题。


![](https://img-blog.csdnimg.cn/img_convert/95608e9062782d28f4f04f821405d99a.png)


同时每个成长路线对应的板块都有配套的视频提供：


![在这里插入图片描述](https://img-blog.csdnimg.cn/direct/a91b9e8100834e9291cfcf1695d8cd42.png#pic_center)


因篇幅有限，仅展示部分资料

**网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。**

**需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注网络安全）**
![img](https://img-blog.csdnimg.cn/img_convert/6ce79003556bfd1103150070712f67df.png)

**一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**

d8cd42.png#pic_center)


因篇幅有限，仅展示部分资料

**网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。**

**需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注网络安全）**
[外链图片转存中...(img-CE4oLVw3-1713340630629)]

**一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**