【Kubernetes】k8s的安全管理详细说明【SA配置、k8s安装dashboard、资源限制（resource
在任何地方一个账号创建出来了，单单从账号本身是没有任何意义的；就像我们去银行开银行卡需要开户一样的，虽然说银行都是有vip和普通用户的，但是单纯的只看账号的话，账号就是一长串的数字而已；在k8s中也是一样的，如果单单只看sa这个账户的话，一个sa被创建出来了，并没有很大的意义的。回归到生活中，为什么银行里面有vip会员，还有更多的普通账户呢？那是因为他们在账户的钱多，钱多了也就变成vip了；那么这
-
在任何地方一个账号创建出来了，单单从账号本身是没有任何意义的；就像我们去银行开银行卡需要开户一样的，虽然说银行都是有vip和普通用户的，但是单纯的只看账号的话，账号就是一长串的数字而已；在k8s中也是一样的，如果单单只看sa这个账户的话，一个sa被创建出来了，并没有很大的意义的。
-
回归到生活中，为什么银行里面有vip会员，还有更多的普通账户呢？那是因为他们在账户的钱多，钱多了也就变成vip了；那么这跟我们k8s中的sa又有什么关系呢？答案是：有关系的。
-
在k8s集群中的sa，也是需要“充钱”进去才能变成“vip”的，这里面的”钱“，就是我们在集群中所说的角色role了，创建一个角色，赋予它一定的权限；但是我们需要将它跟我们所创建出来的角色绑定在一起，那这个sa就会变成”vip“了，那么这个sa的意义就有了。
4、sa有意义了，我们怎样去使用它？
-
现在是万事俱备只欠东风了，账号有了，权限也有了，那么我们怎样去使用它呢？
-
很简单，只要我们在创建新资源的时候（比如说pod、deployment），在yaml文件中指定使用你想指定的sa账户，就可以了；
-
指定了服务账户之后，我们把pod创建出来了，我们在使用这个pod时，这个pod就有了我们指定的账户的权限了，这样就能达到我们在公司中的需求了。
- sa一般和secret对应存在【而sa好像是在启用token的时候就默认存在一个default的了】
[root@master sefe]# kubectl get sa
NAME SECRETS AGE
default 1 2d23h
[root@master sefe]# kubectl get secret
NAME TYPE DATA AGE
default-token-6l8sp kubernetes.io/service-account-token 3 2d23h
[root@master sefe]#
-
前面说过，sa和secret成对存在的，我们创建sa的时候就会自动生成一个secret，而后面，我们也是编辑secret罢了
-
先创建一个sa1 吧
[root@master sefe]# kubectl create sa sa1
serviceaccount/sa1 created
[root@master sefe]# kubectl get sa
NAME SECRETS AGE
default 1 2d23h
sa1 1 4s
[root@master sefe]#
[root@master sefe]# kubectl get secret
NAME TYPE DATA AGE
default-token-6l8sp kubernetes.io/service-account-token 3 2d23h
sa1-token-xg5c9 kubernetes.io/service-account-token 3 12s
[root@master sefe]#
- 上面可以看到自动生成了一个secret
而这个secret呢其实是有一个token秘钥的，这个作用继续往下看，后面就知道了
[root@master sefe]# kubectl describe secrets sa1-token-xg5c9
Name: sa1-token-xg5c9
Namespace: safe
Labels:
Annotations: kubernetes.io/service-account.name: sa1
kubernetes.io/service-account.uid: 4ad27b03-f0af-4c88-8c80-0eb109ff15d2
Type: kubernetes.io/service-account-token
Data
====
ca.crt: 1066 bytes
namespace: 4 bytes
token: eyJhbGciOiJSUzI1NiIsImtpZCI6IlM4MTVVSE5kXzVhZXdMaVN2VDBNcDdvdXV4S25aSmJ0aDVFV3Vhc2FFVVkifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJzYWZlIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6InNhMS10b2tlbi14ZzVjOSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJzYTEiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiI0YWQyN2IwMy1mMGFmLTRjODgtOGM4MC0wZWIxMDlmZjE1ZDIiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6c2FmZTpzYTEifQ.IxLPLq3_izwtCL2wANNQlIYCQtG5NvtR73GKJ_rh71mW6QJxyI0XiMyfbsMBlfnN_66EIqRSmFxzD-P_vsEiw9mgBa2-j_D5sdq-p2n8eehNGMlnoXDmZZvR1oGHfrErDtUMMFbSlsWEjY65KCByjumvTNf73TIC5PCzuUnRmHxKx3leZ_jWNMchSMqtgyRqv9uuXK6lRc9prxGmiBu4SLeYMepQXWXFknY-4fvQxx3zCnaGtMCdX8NYsICIQhtI_8c6C_hivSvib2z3SJJ0FGEvnHJMntcXh11qXyTxg8MuJ5ro0M4yR_RvBMj1qDPkwevj7r_uiT5wJFS4h6jUrQ
[root@master sefe]#
-
语法：
kubectl create clusterrolebinding 自定义名称 --clusterrole=cluster-admin【admin权限，也可以自定义clusterrole】 --serviceaccount=命名空间:sa名称 -
给sa授权呢，其实和clusterrole授权是一样的。
如下：我们创建一个cbindx的clusterrole，并且直接给admin权限，作用是对 上面创建的sa1授权
[root@master sefe]# kubectl create clusterrolebinding cbindx --clusterrole=cluster-admin --serviceaccount=safe:sa1
clusterrolebinding.rbac.authorization.k8s.io/cbindx created
[root@master sefe]#
[root@master sefe]# kubectl get clusterrolebindings.rbac.authorization.k8s.io cbindx
NAME ROLE AGE
cbindx ClusterRole/cluster-admin 25s
[root@master sefe]#
-
上面说过，sa其实是对pod做限制的，所以我们上面创建好sa和授权完毕以后，我们只要在pod文件中增加一行
serviceAccount: sa_name即可 -
如：我给这个pod使用sa的权限，然后创建
[root@master sefe]# cat pod1.yaml
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: pod1
name: pod1
spec:
#nodeName: node2
nodeSelector:
ccx_label: ccxhero
terminationGracePeriodSeconds: 0
containers:
- image: nginx
imagePullPolicy: IfNotPresent
name: pod1
resources: {}
serviceAccount: sa1
dnsPolicy: ClusterFirst
restartPolicy: Always
status: {}
[root@master sefe]#
[root@master sefe]# cat -n pod1.yaml | grep service
18 serviceAccount: sa1
[root@master sefe]#
创建
[root@master sefe]# kubectl apply -f pod1.yaml
pod/pod1 created
[root@master sefe]#
[root@master sefe]# kubectl get pods
NAME READY STATUS RESTARTS AGE
pod1 1/1 Running 0 3s
[root@master sefe]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod1 1/1 Running 0 12s 10.244.104.41 node2
[root@master sefe]#
这里面也可以看到已经使用sa创建该pod了
[root@master sefe]# kubectl edit pod pod1
43 serviceAccount: sa1
44 serviceAccountName: sa1
- 为什么我们说使用sa创建的pod，该pod中的权限是和sa绑定的呢，我们进入容器就可以看到上传创建sa后的secret中的token了
注：下面中的token和我们 在上面创建中看到的token不一致，是正常的
root@pod1:/# df | grep servic
tmpfs 16380928 12 16380916 1% /run/secrets/kubernetes.io/serviceaccount
root@pod1:/# cd /run/secrets/kubernetes.io/serviceaccount
root@pod1:/run/secrets/kubernetes.io/serviceaccount# ls
ca.crt namespace token
root@pod1:/run/secrets/kubernetes.io/serviceaccount# cat token
eyJhbGciOiJSUzI1NiIsImtpZCI6IlM4MTVVSE5kXzVhZXdMaVN2VDBNcDdvdXV4S25aSmJ0aDVFV3Vhc2FFVVkifQ.eyJhdWQiOlsiaHR0cHM6Ly9rdWJlcm5ldGVzLmRlZmF1bHQuc3ZjLmNsdXN0ZXIubG9jYWwiXSwiZXhwIjoxNjY3NzE5NjU5LCJpYXQiOjE2MzYxODM2NTksImlzcyI6Imh0dHBzOi8va3ViZXJuZXRlcy5kZWZhdWx0LnN2Yy5jbHVzdGVyLmxvY2FsIiwia3ViZXJuZXRlcy5pbyI6eyJuYW1lc3BhY2UiOiJzYWZlIiwicG9kIjp7Im5hbWUiOiJwb2QxIiwidWlkIjoiNTVmNjQzNWMtMDYwYy00OGU2LTllZTYtYzk3OTQwZjA2N2IxIn0sInNlcnZpY2VhY2NvdW50Ijp7Im5hbWUiOiJzYTEiLCJ1aWQiOiI0YWQyN2IwMy1mMGFmLTRjODgtOGM4MC0wZWIxMDlmZjE1ZDIifSwid2FybmFmdGVyIjoxNjM2MTg3MjY2fSwibmJmIjoxNjM2MTgzNjU5LCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6c2FmZTpzYTEifQ.DnxdMJrGChaccCUvfQVx2bPP1hOu044eTGNZ2l6BjrwAotbhRr2WlXdJOYTE9ArDD8EuaymQttzJOtvsUSIqI99ZcBjUfwkGWlK8dhJOI-DZ4SWHjax_U-5tuKSZb-JpyXySGfEKzhenCX7Jv8vXJ81LIOm0HOHxLiSx4Y4jYjzbXcHoR8BFtfLAA0NftvkNwgGQ8JdLwerfiNsw3H0EbCUpYVRZagDPCOGFNs_d8bjPKSRy9WQzCr6IEECAeONDaPK1ufUO13KLjddgDvBHGnFZ6OfEZzkQWbnkt-Urb33bH8Du0So0EsX4DfYb5P-Yn-0UJm89x25xK3qgQTfiGwroot@pod1:/run/secrets/kubernetes.io/serviceaccount#
- 这么做 的意义是就是，如果sa给的权限很少，那么这个pod中的功能也就会被限制。
==========================================================================
-
Dashboard 是基于网页的 Kubernetes 用户界面。 你可以使用 Dashboard 将容器应用部署到 Kubernetes 集群中，也可以对容器应用排错，还能管理集群资源。 你可以使用 Dashboard 获取运行在集群中的应用的概览信息，也可以创建或者修改 Kubernetes 资源 （如 Deployment，Job，DaemonSet 等等）。 例如，你可以对 Deployment 实现弹性伸缩、发起滚动升级、重启 Pod 或者使用向导创建新的应用。
-
Dashboard 同时展示了 Kubernetes 集群中的资源状态信息和所有报错信息。
- 这是我自己下载的文件，包含下面所有用到的yaml文件和镜像【也可以继续往下看，自己下载的哈】
- dashboard的yaml文件我们可以去官网获取最新的，也可以看看官方的介绍，不管yaml文件是不是最新的，下面的方法都是一样的哈
官网里面呢，有一个网址，这个就是dashboard的获取地址了，反正地址就是这个，可以在windows上直接打开，然后复制到虚拟机里面，也可以在linux里面wget或curl【但是这个网站是国外的，需要添加解析，有点难访问，而且解析并不是配置后一直能用，这个破网址就折腾了我一上午，艹】
#这个yaml文件呢有306行，这里面集成了dashboard的所有内容，包含ns这些
[root@master sefe]# cat dashboard.yaml | wc -l
306
[root@master sefe]#
- 需要用到2个镜像，可以自己docker pull 也可以打包我上传的。
这个版本不是最新的【可以继续用这个，也可以去找最新的】
[root@ccx ~]# docker pull registry.cn-hangzhou.aliyuncs.com/kube-iamges/metrics-scraper:v1.0.1
v1.0.1: Pulling from kube-iamges/metrics-scraper
4689bc3c8a60: Pull complete
d6f7da934d73: Pull complete
ee60d0f2a8a1: Pull complete
Digest: sha256:3b1cb436dbc2c02aabd7d29e3d9b3f8b4dfc1eb50dbcc63640213ef1139235dd
Status: Downloaded newer image for registry.cn-hangzhou.aliyuncs.com/kube-iamges/metrics-scraper:v1.0.1
registry.cn-hangzhou.aliyuncs.com/kube-iamges/metrics-scraper:v1.0.1
[root@ccx ~]#
[root@ccx ~]# docker pull kubernetesui/dashboard:v2.0.0-beta8
v2.0.0-beta8: Pulling from kubernetesui/dashboard
5cd0d71945f0: Pull complete
Digest: sha256:fc90baec4fb62b809051a3227e71266c0427240685139bbd5673282715924ea7
Status: Downloaded newer image for kubernetesui/dashboard:v2.0.0-beta8
docker.io/kubernetesui/dashboard:v2.0.0-beta8
[root@ccx ~]#
- 上面2个镜像弄完以后呢，需要导入到所有node节点
因为我的集群是没有外网的，所以我在上面有外网的机器上docker pull以后，上传到我服务器的，如果你是下载的我的镜像，你也需要这么做。
#拷贝到所有node节点
[root@master sefe]# scp dashboard* node1:~
root@node1’s password:
dashboard-metrics_v1.0.1.tar 100% 38MB 19.1MB/s 00:02
dashboard_v2.0.0.tar 100% 87MB 18.3MB/s 00:04
dashboard.yaml 100% 7807 2.7MB/s 00:00
[root@master sefe]# scp dashboard* node2:~
root@node2’s password:
dashboard-metrics_v1.0.1.tar 100% 38MB 20.5MB/s 00:01
dashboard_v2.0.0.tar 100% 87MB 19.8MB/s 00:04
dashboard.yaml 100% 7807 2.6MB/s 00:00
[root@master sefe]#
node1解压镜像
[root@node1 ~]# docker load -i dashboard
dashboard-metrics_v1.0.1.tar dashboard_v2.0.0.tar dashboard.yaml
[root@node1 ~]# docker load -i dashboard_v2.0.0.tar
954115f32d73: Loading layer 91.22MB/91.22MB
Loaded image: registry.cn-hangzhou.aliyuncs.com/kube-iamges/dashboard:v2.0.0-beta8
[root@node1 ~]# docker load -i dashboard-metrics_v1.0.1.tar
89ac18ee460b: Loading layer 238.6kB/238.6kB
878c5d3194b0: Loading layer 39.87MB/39.87MB
1dc71700363a: Loading layer 2.048kB/2.048kB
Loaded image: registry.cn-hangzhou.aliyuncs.com/kube-iamges/metrics-scraper:v1.0.1
[root@node1 ~]#
node2解压镜像
[root@node2 ~]# docker load -i dashboard-metrics_v1.0.1.tar
89ac18ee460b: Loading layer 238.6kB/238.6kB
878c5d3194b0: Loading layer 39.87MB/39.87MB
1dc71700363a: Loading layer 2.048kB/2.048kB
Loaded image: registry.cn-hangzhou.aliyuncs.com/kube-iamges/metrics-scraper:v1.0.1
[root@node2 ~]# docker load -i dashboard_v2.0.0.tar
954115f32d73: Loading layer 91.22MB/91.22MB
Loaded image: registry.cn-hangzhou.aliyuncs.com/kube-iamges/dashboard:v2.0.0-beta8
[root@node2 ~]#
yaml文件编辑
-
这主要修改imges相关的内容【NodePort后面用另外一种方式修改】
-
1、修改镜像名称，用我们上面下载的2个镜像名称
-
2、修改imagePullPolicy策略为本地获取，第二个imagePullPolicy是手动增加的
[root@master sefe]# grep image dashboard.yaml
image: registry.cn-hangzhou.aliyuncs.com/kube-iamges/dashboard:v2.0.0-beta8
#image: kubernetesui/dashboard:v2.2.0
#imagePullPolicy: Always
imagePullPolicy: IfNotPresent
#image: kubernetesui/metrics-scraper:v1.0.6
image: registry.cn-hangzhou.aliyuncs.com/kube-iamges/metrics-scraper:v1.0.1
imagePullPolicy: IfNotPresent
[root@master sefe]#
生成dashboard的pod
- 生成yaml文件和查看该pod【状态需要为running为正常】
[root@master sefe]# kubectl apply -f dashboard.yaml
namespace/kubernetes-dashboard created
serviceaccount/kubernetes-dashboard created
service/kubernetes-dashboard created
secret/kubernetes-dashboard-certs created
secret/kubernetes-dashboard-csrf created
secret/kubernetes-dashboard-key-holder created
configmap/kubernetes-dashboard-settings created
role.rbac.authorization.k8s.io/kubernetes-dashboard created
clusterrole.rbac.authorization.k8s.io/kubernetes-dashboard created
rolebinding.rbac.authorization.k8s.io/kubernetes-dashboard created
clusterrolebinding.rbac.authorization.k8s.io/kubernetes-dashboard created
deployment.apps/kubernetes-dashboard created
service/dashboard-metrics-scraper created
deployment.apps/dashboard-metrics-scraper created
[root@master sefe]#
[root@master sefe]# kubectl get pods -n kubernetes-dashboard
NAME READY STATUS RESTARTS AGE
dashboard-metrics-scraper-684f96bd4-bhq4c 1/1 Running 0 66s
kubernetes-dashboard-5d66bcd8fd-hbqhw 1/1 Running 0 66s
[root@master sefe]#
- 前面说过这个会自动生成一个ns空间，所以我们现在查看这个ns下的所有pod
[root@master sefe]# kubectl get all -n kubernetes-dashboard
NAME READY STATUS RESTARTS AGE
pod/dashboard-metrics-scraper-684f96bd4-bhq4c 1/1 Running 0 17s
pod/kubernetes-dashboard-5d66bcd8fd-hbqhw 1/1 Running 0 17s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/dashboard-metrics-scraper ClusterIP 10.101.25.25 8000/TCP 17s
service/kubernetes-dashboard ClusterIP 10.107.102.121 443/TCP 17s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/dashboard-metrics-scraper 1/1 1 1 17s
deployment.apps/kubernetes-dashboard 1/1 1 1 17s
NAME DESIRED CURRENT READY AGE
replicaset.apps/dashboard-metrics-scraper-684f96bd4 1 1 1 17s
replicaset.apps/kubernetes-dashboard-5d66bcd8fd 1 1 1 17s
[root@master sefe]#
修改dashboard的svc类型并测试
- 修改前呢是
ClusterIP，现在我们要将这个修改为NodePort
#首先需要查看dashboard的名称
[root@master sefe]# kubectl get svc -n kubernetes-dashboard
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
dashboard-metrics-scraper ClusterIP 10.101.25.25 8000/TCP 2m59s
kubernetes-dashboard ClusterIP 10.107.102.121 443/TCP 2m59s
然后编辑这个名称，注意，这是在下面固定的命名空间下的
[root@master sefe]# kubectl edit svc kubernetes-dashboard -n kubernetes-dashboard
#修改下面这一行内容，然后wq保存退出
…
type: NodePort #修改这行为这个内容【倒数第三行】
status:
loadBalancer: {}
~
:wq
[root@master sefe]#
修改完毕以后呢，就可以看到PORT中的dashboard多了一个TCP端口号了，如这31526
[root@master sefe]# kubectl get svc -n kubernetes-dashboard
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
dashboard-metrics-scraper ClusterIP 10.101.25.25 8000/TCP 5m54s
kubernetes-dashboard NodePort 10.107.102.121 443:31526/TCP 5m54s
- 然后
crul -k https://master主机ip:svc端口测试看是否有内容【有内容为正常】
[root@master sefe]# curl -k https://192.168.59.142:31526
<!doctype html>
type=“image/png”
href=“assets/images/kubernetes-logo.png” />
<meta name=“viewport”
content=“width=device-width”>
[root@master sefe]# systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled)
Active: inactive (dead)
Docs: man:firewalld(1)
[root@master sefe]#
- 并且此时呢，我们就可以t通过
https://master主机ip:svc端口在浏览器中访问dashboard了【第一次访问需要接收并添加列外】
使用token登录，token获取继续往下看
访问报错Internet Explorer增强安全配置。。。
- 报错内容如下
我这系统是server2012，普通windows可能没有这种报错。。。反正有的话这么处理就是了
- 处理方法
打开服务器管理器，点击本地服务器，可以看到IE增强安全配置是启用状态，点击将IE增强安全配置修改为禁用状态，再重新打开IE浏览器，可以正常访问网页，不再弹出该弹窗。
端口通但浏览器无法访问
- 如下，dashboard映射的端口通，但浏览器就是无法访问【此时linux中是可以正常访问的】
-
原因和解决方法
-
原因是：使用的浏览器是IE内核，这玩意不支持IE内核
-
解决方法：换firefox浏览器即可【火狐浏览器】
查看token值并登陆
- 上面我们网址登录的时候看到了可以选择token登陆
现在我们查看token
之前我们说过每当创建一个sa就会自动生成一个secrets，而token是记录在secrets中的。
#先查看secrets
[root@master sefe]# kubectl get secrets -n kubernetes-dashboard
NAME TYPE DATA AGE
default-token-4pqr6 kubernetes.io/service-account-token 3 129m
kubernetes-dashboard-certs Opaque 0 129m
kubernetes-dashboard-csrf Opaque 1 129m
kubernetes-dashboard-key-holder Opaque 2 129m
kubernetes-dashboard-token-6bnkg kubernetes.io/service-account-token 3 129m
[root@master sefe]#
[root@master sefe]# kubectl get sa -n kubernetes-dashboard
NAME SECRETS AGE
default 1 130m
kubernetes-dashboard 1 130m
[root@master sefe]#
sa对应的token格式呢是：xx-token-xx
#我们现在查看这个secrets的详细即可看到token内容
[root@master sefe]# kubectl describe kubernetes-dashboard-token-6bnkg -n kubernetes-dashboard
error: the server doesn’t have a resource type “kubernetes-dashboard-token-6bnkg”
[root@master sefe]# kubectl describe secrets kubernetes-dashboard-token-6bnkg -n kubernetes-dashboard
Name: kubernetes-dashboard-token-6bnkg
Namespace: kubernetes-dashboard
Labels:
Annotations: kubernetes.io/service-account.name: kubernetes-dashboard
kubernetes.io/service-account.uid: b9f8b781-3eb6-47e6-a6cb-ff5cb4372683
Type: kubernetes.io/service-account-token
Data
====
ca.crt: 1066 bytes
namespace: 20 bytes
token: eyJhbGciOiJSUzI1NiIsImtpZCI6IlM4MTVVSE5kXzVhZXdMaVN2VDBNcDdvdXV4S25aSmJ0aDVFV3Vhc2FFVVkifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlcm5ldGVzLWRhc2hib2FyZCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJrdWJlcm5ldGVzLWRhc2hib2FyZC10b2tlbi02Ym5rZyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJrdWJlcm5ldGVzLWRhc2hib2FyZCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6ImI5ZjhiNzgxLTNlYjYtNDdlNi1hNmNiLWZmNWNiNDM3MjY4MyIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDprdWJlcm5ldGVzLWRhc2hib2FyZDprdWJlcm5ldGVzLWRhc2hib2FyZCJ9.tQ-_K-rsXRNIbHJRff0XiEVD9sr7qi_hEFTTgeaD0D8iLzELCDVqiDoVp95SHQyUi3-kbestzxm5C-djUd45loJpZNId3jpmNhW5sKQ4nrxqmT575SDoQSm98_3nAw0r80iuFfxJhA0puH6hltZzf4yTN6cJKetEiwkFmFOi7UWQMfNoJREppdaMFUK96O_SIEHvIHsHl2qcvw5ZttFHcE2w5FVOPYbB0JIoWxyRAZGonyshraYrPGnKwfkUTn18UYlHksP8oJEhT2Y05X9wlp-H0n-0GEjdcFl03ov3WrXxdhgBhJhPq62fztRC6S2voyjHuD-JbvGdLNtpX7QFGA
[root@master sefe]#
- 复制这个token值，然后复制到浏览器中【很长，注意要复制完】
- 现在登陆进去以后呢，是没有内容的，而且一直有警告，是正常的，因为没有给sa授权
SA授权并验证
- 先授权吧
#dashboard自定义名称
#cluster-admin给admin权限
#kubernetes-dashboard:kubernetes-dashboard两个都是sa名称【中间有冒号】
[root@master sefe]# kubectl create clusterrolebinding dashboard --clusterrole=cluster-admin --serviceaccount=kubernetes-dashboard:kubernetes-dashboard
clusterrolebinding.rbac.authorization.k8s.io/dashboard created
[root@master sefe]#
[root@master sefe]# kubectl describe clusterrolebindings.rbac.authorization.k8s.io dashboard
Name: dashboard
Labels:
Annotations:
Role:
Kind: ClusterRole
Name: cluster-admin
Subjects:
Kind Name Namespace
ServiceAccount kubernetes-dashboard kubernetes-dashboard
[root@master sefe]#
- 现在我们刷新浏览器，就可以看到dashboard已经有内容并且告警也没有 了
至此dashboard就配置完了，dashboard的功能其实挺多的，连集群的使用率都能看到，更多功能自行摸索吧。。。
===================================================================
- 我们用cenos镜像来做测试吧，然后准备一个内存消耗的文件【脚本也行，可以自行随便准备一个】
#node节点有centos
[root@node2 ~]# docker images | grep cen
hub.c.163.com/library/centos latest 328edcd84f1b 4 years ago 193MB
[root@node2 ~]#
内存消耗rpm包
[root@master sefe]# ls | grep mem
memload-7.0-1.r29766.x86_64.rpm
[root@master sefe]#
- 测试资源限制前呢，我们先来看看资源没有被限制的时候是什么样子的【条件不方便呢也可以不用做这些测试，比较这个呢，是比较简单直观的东西，不想弄可以不弄，看看我弄的过程就行了，应该很好理解的，而且这个代码也就那么点，真实环境限制也不容易出错。】
#有pod，先删了吧
[root@master sefe]# kubectl get pods
NAME READY STATUS RESTARTS AGE
pod1 1/1 Running 0 41m
[root@master sefe]# kubectl delete pod pod1
pod “pod1” deleted
[root@master sefe]#
我们用centos镜像来做测试，如下，创建好pod并安装好内存消耗的包
[root@master sefe]# cat pod2.yaml
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: pod2
name: pod2
spec:
#nodeName: node2
#nodeSelector:
ccx_label: ccxhero
terminationGracePeriodSeconds: 0
containers:
- image: hub.c.163.com/library/centos
command: [“sh”,“-c”,“sleep 1000000”]
imagePullPolicy: IfNotPresent
name: pod2
resources: {}
dnsPolicy: ClusterFirst
restartPolicy: Always
status: {}
[root@master sefe]#
[root@master sefe]# kubectl apply -f pod2.yaml
pod/pod2 created
[root@master sefe]# kubectl get pods
NAME READY STATUS RESTARTS AGE
pod2 1/1 Running 0 5s
[root@master sefe]#
[root@master sefe]# kubectl cp memload-7.0-1.r29766.x86_64.rpm pod2:/opt
[root@master sefe]# kubextl exec -it pod2 – bash
bash: kubextl: command not found…
[root@master sefe]# kubectl exec -it pod2 – bash
[root@pod2 /]# ls /opt
memload-7.0-1.r29766.x86_64.rpm
[root@pod2 /]# rpm -ivh /opt/memload-7.0-1.r29766.x86_64.rpm
Preparing… ################################# [100%]
Updating / installing…
1:memload-7.0-1.r29766 ################################# [100%]
[root@pod2 /]#
- 基本环境弄好了，我们现在开始消耗内存看看
我下面是在多个窗口中，注意看主机名 的变化
这个pod是在node2上
[root@master ~]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod2 1/1 Running 0 7m18s 10.244.104.42 node2
[root@master ~]#
可以看到node2现在消耗了1G内存
[root@node2 ~]# free -g
total used free shared buff/cache available
Mem: 31 1 28 0 1 29
Swap: 0 0 0
[root@node2 ~]#
#现在回到容器内部开始占用内容，因为我这虚机是32G内存，所以我占用多一点吧
#容器中占用了10G
[root@pod2 /]# memload 10240
Attempting to allocate 10240 Mebibytes of resident memory…
回到node2，可以看到10G确实可以被占用的
[root@node2 ~]# free -g
total used free shared buff/cache available
Mem: 31 1 28 0 1 29
Swap: 0 0 0
[root@node2 ~]# free -g
total used free shared buff/cache available
Mem: 31 4 24 0 1 25
Swap: 0 0 0
[root@node2 ~]#
[root@node2 ~]# free -g
total used free shared buff/cache available
Mem: 31 7 22 0 1 23
Swap: 0 0 0
[root@node2 ~]# free -g
total used free shared buff/cache available
Mem: 31 8 21 0 1 22
Swap: 0 0 0
[root@node2 ~]# free -g
total used free shared buff/cache available
Mem: 31 11 18 0 1 19
Swap: 0 0 0
[root@node2 ~]#
- 上面呢是可以正常释放的，现在我们释放掉占用的这10G
#容器ctrl+c即可释放
[root@pod2 /]# memload 10240
Attempting to allocate 10240 Mebibytes of resident memory…
Allocated 10000 pages
^C
[root@pod2 /]#
回到node2看是否已经被释放，然后再释放下缓存内存
[root@node2 ~]# free -g
total used free shared buff/cache available
Mem: 31 1 28 0 1 29
Swap: 0 0 0
[root@node2 ~]# echo 3 > /proc/sys/vm/drop_caches
[root@node2 ~]#
[root@node2 ~]# free -g
total used free shared buff/cache available
Mem: 31 1 29 0 0 29
Swap: 0 0 0
[root@node2 ~]#
- 支持资源占用测试呢，就完了反正是没有限制的时候想弄多少弄多少
现在，我们吧这pod删了吧。
[root@pod2 /]# exit
exit
command terminated with exit code 130
[root@master sefe]# kubectl delete pod pod2
pod “pod2” deleted
[root@master sefe]#
作用： 用来限制每个pod的资源
代码参数说明
-
就不多累赘了，反正资源限制就是这个字面意思，应该很好理解，而这个也不过是实现限制的一种方式罢了，所以没有必要过于深究原理，直接说操作吧。
-
我放一段代码吧，在代码中做参数说明应该更容易理解一点
为了看着方便，我删了其他自动内容，只保留resource部分
#没有资源限制的时候呢，是这样子的
resources: {}
#限制以后呢，｛｝没了，成下面样子了
#内存可以cpu都是可以选的，可以单独存在，也可以同时存在
resources:
requests: # —容器所在节点 资源的最小值
memory: “256Mi” #内存限制，单位是M【G的单位是Gi】
cpu: “500m” #cpu限制，单位是微核心【下面会单独对微核心做说明】
limits: # —容器消耗资源最大值
memory: “512Mi”#内存限制，单位是M【G的单位是Gi】
cpu: “1000m”#cpu限制，单位是微核心【下面会单独对微核心做说明】
- 微核心说明：
在kubernetets系统上，1个单位的CPU相当于虚拟机上的一颗虚拟CPU（vCPU）或者物理机上的一个超线（HyperThread，或者称一个逻辑CPU），它支持分数计量方式，一个核心（1 core）相当于1000个微核心（millicores），因此500m相当于是0.5个核心，即二分之一个核心。
测试说明【内存】
最小值限制
- 这个最小值呢存在一个逻辑问题，就是说如果设置的最小值大于了能部署的node节点内存，那么该pod就不会被创建成功，状态会一直处于pending状态
如，我现在的内存是32G，我现在指定最小内存100G创建pod试试
前面说过，这些限制是可以单独存在的，所以我这只限制最低内存
[root@master sefe]# cat pod2.yaml
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: pod2
name: pod2
spec:
#nodeName: node2
#nodeSelector:
ccx_label: ccxhero
terminationGracePeriodSeconds: 0
containers:
- image: hub.c.163.com/library/centos
command: [“sh”,“-c”,“sleep 1000000”]
imagePullPolicy: IfNotPresent
name: pod2
resources:
requests:
memory: 100Gi
dnsPolicy: ClusterFirst
restartPolicy: Always
status: {}
[root@master sefe]#
[root@master sefe]# kubectl apply -f pod2.yaml
pod/pod2 created
[root@master sefe]#
[root@master sefe]# kubectl get pods
NAME READY STATUS RESTARTS AGE
pod2 0/1 Pending 0 3s
[root@master sefe]#
[root@master sefe]# kubectl delete pod pod2
pod “pod2” deleted
[root@master sefe]#
最大值限制
- 现在呢，我限制内存的最大值为5G，也就是说，该pod最多能使用5G内存
[root@master sefe]# cat pod2.yaml
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: pod2
name: pod2
spec:
#nodeName: node2
#nodeSelector:
ccx_label: ccxhero
terminationGracePeriodSeconds: 0
containers:
- image: hub.c.163.com/library/centos
command: [“sh”,“-c”,“sleep 1000000”]
imagePullPolicy: IfNotPresent
name: pod2
resources:
requests:
memory: 1Gi
cpu: 100m
limits:
memory: 5Gi
dnsPolicy: ClusterFirst
restartPolicy: Always
status: {}
[root@master sefe]# kubectl apply -f pod2.yaml
pod/pod2 created
[root@master sefe]# kubectl get pods
NAME READY STATUS RESTARTS AGE
pod2 0/1 ContainerCreating 0 3s
[root@master sefe]# kubectl get pods
NAME READY STATUS RESTARTS AGE
pod2 1/1 Running 0 5s
[root@master sefe]#
[root@master ~]# kubectl get pods -owide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod2 1/1 Running 0 3m3s 10.244.104.19 node2
[root@master ~]#
- 现在测试看是否真是这样
[root@master sefe]# kubectl cp memload-7.0-1.r29766.x86_64.rpm pod2:/opt
[root@master sefe]# kubectl exec -it pod2 – bash
[root@pod2 /]# rpm -ivh /opt/memload-7.0-1.r29766.x86_64.rpm
Preparing… ################################# [100%]
Updating / installing…
1:memload-7.0-1.r29766 ################################# [100%]
[root@pod2 /]#
先占用2G，没问题
[root@pod2 /]# memload 2048
Attempting to allocate 2048 Mebibytes of resident memory…
#node2也确实被占用了
[root@node2 ~]# free -g
total used free shared buff/cache available
Mem: 31 3 27 0 0 27
Swap: 0 0 0
[root@node2 ~]#
现在占用6G试试【会失败，因为最多只能占用5G】
#可以看到被killed了，占用失败，没问题
[root@pod2 /]# memload 6000
Attempting to allocate 6000 Mebibytes of resident memory…
Killed
[root@pod2 /]#
- 正常区间的限制呢，我就不说了，根据实际大小来控制的话，是不会有意外的。
测试说明【cpu】【使用率计算】
-
注意：内存和cpu限制规则和逻辑是完全一样，所以我就不对cpu单独说明了，有不会的看看上面内存方法吧
-
需要注意的就是，占用cpu微核心数量的时候需要简单计算一下【计算微核心的逻辑呢，看完就懂了】
-
因为cpu是微核心为单位，所以呢，我这说明一下为核心的计算吧
[root@master sefe]# lscpu| grep CPU
CPU op-mode(s): 32-bit, 64-bit
CPU(s): 16
On-line CPU(s) list: 0-15
CPU family: 6
Model name: Intel® Xeon® CPU E7-4820 v3 @ 1.90GHz
CPU MHz: 1895.436
NUMA node0 CPU(s): 0-15
[root@master sefe]#
[root@master sefe]# kubectl top nodes
W1106 16:48:46.634284 47766 top_node.go:119] Using json format to get metrics. Next release will switch to protocol-buffers, switch early by passing --use-protocol-buffers flag
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
master 478m 2% 2048Mi 6%
node1 248m 1% 1265Mi 3%
node2 174m 1% 857Mi 2%
[root@master sefe]#
- 以上面的master为例，总共是16颗cpu，那么总公就有16000m的微核心
所以使用率就是478/16000=0.0298，但是top呢是只显示整数的
作用： 用来限制每个pod的资源
一个LimitRange资源对象可以提供的功能
-
在一个命名空间中实施对每个 Pod 或 Container 最小和最大的资源使用量的限制。
-
在一个命名空间中实施对每个 PersistentVolumeClaim 能申请的最小和最大的存储空间大小的限制。
-
在一个命名空间中实施对一种资源的申请值和限制值的比值的控制。
-
设置一个命名空间中对计算资源的默认申请/限制值，并且自动的在运行时注入到多个 Container 中。
LimitRange资源参数使用说明
- (1) 在LimitRange中，Pod和Container都可以设置
min、max和maxLimitRequestRatio这三个参数
而Container还可以设置defaultRequest和defaultLimit这两个参数，而Pod不可以设置这两个参数。
-
Container下的参数解释【一般使用这个】
-
min是Pod中所有容器的Requests值的下限 -
max是Pod中所有容器的Limits值的上限 -
defaultRequest是Pod中所有未指定Requests值的容器的默认Requests值 -
defaultLimit是Pod中所有未指定Limits值的容器的默认Limits值 -
maxLimitRequestRatio用于限定Pod中所有容器的Limits值与Requests值得比例上限 -
Pod下得参数解析
-
min是Pod中所有容器的Requests值的总和下限 -
max是Pod中所有容器得Limits值的总和上限 -
maxLimitRequestRatio用于限定Pod中所有容器的Limits值总和与Requests值总和的比例上限 -
再说一遍，创建的limit是对命名空间生效的【如果不指定ns，则默认当前的ns空间生效】，在创建limit的ns中，所有pod都会应用这个资源限制规则。
创建和查看Limit
- 这个呢，实际上也就是一个yaml文件，格式如下，具体使用呢，可以根据上面的资源参数使用说明中套过来哈，我这只是做一些简单的说明罢了
#最基本的limit文件格式 如下【可以同时存在多样】
#具体怎么使用看需求吧，限制格式看上面资源使用说明
[root@master sefe]# cat limit.yaml
apiVersion: v1
kind: LimitRange
metadata:
name: mem-min-max-demo-lr
#namespace: ns1
spec:
limits:
- max:
memory: 5Gi
min:
memory: 512Mi
type: Container
[root@master sefe]#
创建limit
[root@master sefe]# kubectl apply -f limit.yaml
limitrange/mem-min-max-demo-lr created
[root@master sefe]#
查看limit
[root@master sefe]# kubectl get -f limit.yaml
NAME CREATED AT
mem-min-max-demo-lr 2021-11-06T09:11:43Z
查看limit详情【另一种查看方式】
[root@master sefe]# kubectl describe limits mem-min-max-demo-lr
Name: mem-min-max-demo-lr
Namespace: safe
Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio
Container memory 512Mi 5Gi 5Gi 5Gi -
[root@master sefe]#
测试说明【内存】
- 这个因为是定义的规则，所以在当前命名空间中的所有pod都生效，所以就正儿八经的值测试最大值了，最小值如果大于node内存的话，创建pod的状态也会成pending。
[root@master sefe]# cat limit.yaml
apiVersion: v1
kind: LimitRange
metadata:
name: mem-min-max-demo-lr
#namespace: ns1
spec:
limits:
- max:
memory: 5Gi
min:
memory: 512Mi
type: Container
[root@master sefe]#
[root@master sefe]# kubectl apply -f limit.yaml
limitrange/mem-min-max-demo-lr created
[root@master sefe]#
[root@master sefe]# kubectl get limitranges limit.yaml
Error from server (NotFound): limitranges “limit.yaml” not found
[root@master sefe]# kubectl get -f limit.yaml
NAME CREATED AT
mem-min-max-demo-lr 2021-11-06T09:11:43Z
[root@master sefe]# kubectl describe limits mem-min-max-demo-lr
Name: mem-min-max-demo-lr
Namespace: safe
Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio
Container memory 512Mi 5Gi 5Gi 5Gi -
[root@master sefe]#
- 如上，我创建了一个最大内存为5G的limit，现在测试是否生效
得从创建pod开始啊，因为定义了limit，所以呢就不需要resource了
[root@master sefe]# cat pod2.yaml
apiVersion: v1
kind: Pod
metadata:
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数网络安全工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年网络安全全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上网络安全知识点，真正体系化！
由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新
如果你觉得这些内容对你有帮助，可以添加VX：vip204888 （备注网络安全获取）
如何自学黑客&网络安全
黑客零基础入门学习路线&规划
初级黑客
1、网络安全理论知识（2天）
①了解行业相关背景，前景，确定发展方向。
②学习网络安全相关法律法规。
③网络安全运营的概念。
④等保简介、等保规定、流程和规范。（非常重要）
2、渗透测试基础（一周）
①渗透测试的流程、分类、标准
②信息收集技术：主动/被动信息搜集、Nmap工具、Google Hacking
③漏洞扫描、漏洞利用、原理，利用方法、工具（MSF）、绕过IDS和反病毒侦察
④主机攻防演练：MS17-010、MS08-067、MS10-046、MS12-20等
3、操作系统基础（一周）
①Windows系统常见功能和命令
②Kali Linux系统常见功能和命令
③操作系统安全（系统入侵排查/系统加固基础）
4、计算机网络基础（一周）
①计算机网络基础、协议和架构
②网络通信原理、OSI模型、数据转发流程
③常见协议解析（HTTP、TCP/IP、ARP等）
④网络攻击技术与网络安全防御技术
⑤Web漏洞原理与防御：主动/被动攻击、DDOS攻击、CVE漏洞复现
5、数据库基础操作（2天）
①数据库基础
②SQL语言基础
③数据库安全加固
6、Web渗透（1周）
①HTML、CSS和JavaScript简介
②OWASP Top10
③Web漏洞扫描工具
④Web渗透工具：Nmap、BurpSuite、SQLMap、其他（菜刀、漏扫等）
恭喜你，如果学到这里，你基本可以从事一份网络安全相关的工作，比如渗透测试、Web 渗透、安全服务、安全分析等岗位；如果等保模块学的好，还可以从事等保工程师。薪资区间6k-15k
到此为止，大概1个月的时间。你已经成为了一名“脚本小子”。那么你还想往下探索吗？
如果你想要入坑黑客&网络安全，笔者给大家准备了一份：282G全网最全的网络安全资料包评论区留言即可领取！
7、脚本编程（初级/中级/高级）
在网络安全领域。是否具备编程能力是“脚本小子”和真正黑客的本质区别。在实际的渗透测试过程中，面对复杂多变的网络环境，当常用工具不能满足实际需求的时候，往往需要对现有工具进行扩展，或者编写符合我们要求的工具、自动化脚本，这个时候就需要具备一定的编程能力。在分秒必争的CTF竞赛中，想要高效地使用自制的脚本工具来实现各种目的，更是需要拥有编程能力.
如果你零基础入门，笔者建议选择脚本语言Python/PHP/Go/Java中的一种，对常用库进行编程学习；搭建开发环境和选择IDE,PHP环境推荐Wamp和XAMPP， IDE强烈推荐Sublime；·Python编程学习，学习内容包含：语法、正则、文件、 网络、多线程等常用库，推荐《Python核心编程》，不要看完；·用Python编写漏洞的exp,然后写一个简单的网络爬虫；·PHP基本语法学习并书写一个简单的博客系统；熟悉MVC架构，并试着学习一个PHP框架或者Python框架 (可选)；·了解Bootstrap的布局或者CSS。
8、超级黑客
这部分内容对零基础的同学来说还比较遥远，就不展开细说了，附上学习路线。
网络安全工程师企业级学习路线
如图片过大被平台压缩导致看不清的话，评论区点赞和评论区留言获取吧。我都会回复的
视频配套资料&国内外网安书籍、文档&工具
当然除了有配套的视频，同时也为大家整理了各种文档和书籍资料&工具，并且已经帮大家分好类了。
一些笔者自己买的、其他平台白嫖不到的视频教程。
一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
cking
③漏洞扫描、漏洞利用、原理，利用方法、工具（MSF）、绕过IDS和反病毒侦察
④主机攻防演练：MS17-010、MS08-067、MS10-046、MS12-20等
3、操作系统基础（一周）
①Windows系统常见功能和命令
②Kali Linux系统常见功能和命令
③操作系统安全（系统入侵排查/系统加固基础）
4、计算机网络基础（一周）
①计算机网络基础、协议和架构
②网络通信原理、OSI模型、数据转发流程
③常见协议解析（HTTP、TCP/IP、ARP等）
④网络攻击技术与网络安全防御技术
⑤Web漏洞原理与防御：主动/被动攻击、DDOS攻击、CVE漏洞复现
5、数据库基础操作（2天）
①数据库基础
②SQL语言基础
③数据库安全加固
6、Web渗透（1周）
①HTML、CSS和JavaScript简介
②OWASP Top10
③Web漏洞扫描工具
④Web渗透工具：Nmap、BurpSuite、SQLMap、其他（菜刀、漏扫等）
恭喜你，如果学到这里，你基本可以从事一份网络安全相关的工作，比如渗透测试、Web 渗透、安全服务、安全分析等岗位；如果等保模块学的好，还可以从事等保工程师。薪资区间6k-15k
到此为止，大概1个月的时间。你已经成为了一名“脚本小子”。那么你还想往下探索吗？
如果你想要入坑黑客&网络安全，笔者给大家准备了一份：282G全网最全的网络安全资料包评论区留言即可领取！
7、脚本编程（初级/中级/高级）
在网络安全领域。是否具备编程能力是“脚本小子”和真正黑客的本质区别。在实际的渗透测试过程中，面对复杂多变的网络环境，当常用工具不能满足实际需求的时候，往往需要对现有工具进行扩展，或者编写符合我们要求的工具、自动化脚本，这个时候就需要具备一定的编程能力。在分秒必争的CTF竞赛中，想要高效地使用自制的脚本工具来实现各种目的，更是需要拥有编程能力.
如果你零基础入门，笔者建议选择脚本语言Python/PHP/Go/Java中的一种，对常用库进行编程学习；搭建开发环境和选择IDE,PHP环境推荐Wamp和XAMPP， IDE强烈推荐Sublime；·Python编程学习，学习内容包含：语法、正则、文件、 网络、多线程等常用库，推荐《Python核心编程》，不要看完；·用Python编写漏洞的exp,然后写一个简单的网络爬虫；·PHP基本语法学习并书写一个简单的博客系统；熟悉MVC架构，并试着学习一个PHP框架或者Python框架 (可选)；·了解Bootstrap的布局或者CSS。
8、超级黑客
这部分内容对零基础的同学来说还比较遥远，就不展开细说了，附上学习路线。
网络安全工程师企业级学习路线
如图片过大被平台压缩导致看不清的话，评论区点赞和评论区留言获取吧。我都会回复的
视频配套资料&国内外网安书籍、文档&工具
当然除了有配套的视频，同时也为大家整理了各种文档和书籍资料&工具，并且已经帮大家分好类了。
一些笔者自己买的、其他平台白嫖不到的视频教程。
一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
[外链图片转存中…(img-MdIuqmVh-1712874905990)]
K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容
更多推荐
28
0- 0
已为社区贡献1条内容
所有评论(0)