【Kubernetes】k8s的安全管理详细说明【SA配置、k8s安装dashboard、资源限制(1)

给大家的福利

零基础入门

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

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

在这里插入图片描述

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

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

需要这份系统化资料的朋友,可以点击这里获取

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

[root@master2 ~]#

token验证&&kubeconfig验证

====================================================================================

内容过多,分开发布,token验证&&kubeconfig验证去这篇博客:

【Kubernetes】k8s的安全管理详细说明【k8s框架说明、token验证和kubeconfig验证详细说明】

role和clusterrole赋权

=================================================================================

内容过多,分开发布,token验证&&kubeconfig验证去这篇博客:

【Kubernetes】k8s的安全管理详细说明【role赋权和clusterrole赋权详细配置说明】

sa【Service Account】

==================================================================================

sa总结


1、service account到底是什么?

  • 在k8s中,service account是给集群中的进程使用的,当集群中的pod/进程需要跟apiserver申请调用资源时使用时使用的;我们用户是不会去使用它的;举个很形象的例子,就像nginx服务中的nginx账号一样,我们一般是不会使用su去登录它并且使用它的;如下,就能很直观的明白了:

For more information on configuration, see:

* Official English Documentation: http://nginx.org/en/docs/

* Official Russian Documentation: http://nginx.org/ru/docs/

user nginx; #这里这个账户就叫nginx,就是给nginx这个进程、服务使用的

worker_processes auto;

error_log /var/log/nginx/error.log;

pid /run/nginx.pid;

Load dynamic modules. See /usr/share/doc/nginx/README.dynamic.

include /usr/share/nginx/modules/*.conf;

events {

worker_connections 1024;

  • 但是不同的是,linux中的nginx服务,我们使用yum -y install下载nginx服务时,系统会默认帮我们创建一个叫做nginx的账户;

  • 但是在k8s中,任何进程任何pod在被创建出来的同时,如果我们不指定使用自己创建的service account的话,系统会默认给我们使用default账户去创建资源

2、在k8s集群中为什么需要service account?

  • 原因很简单,在创建新的资源的同时,限制它们的权限;

  • 因为在我们创建新的资源时,如果不指定使用哪个sa去创建的话,默认就是使用default服务账户,但是default这个服务账号权限特别大,任何操作都能执行,在公司中我们是不允许这样的事情发生的;主要的原因就是为了保护资源,防止误删

  • 所以这个时候我们就需要用到service account了,对资源限制权限,给它我们想给的权限,这样就能有效的保护好我们资源

3、创建出来的sa可以直接就使用吗?

  • 但是一个sa创建出来了有什么用呢?这个问题值得深思

  • 在任何地方一个账号创建出来了,单单从账号本身是没有任何意义的;就像我们去银行开银行卡需要开户一样的,虽然说银行都是有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


  • 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成对存在的,我们创建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]#

给sa授权


  • 语法: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


  • 上面说过,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

==========================================================================

说明


  • Dashboard 是基于网页的 Kubernetes 用户界面。 你可以使用 Dashboard 将容器应用部署到 Kubernetes 集群中,也可以对容器应用排错,还能管理集群资源。 你可以使用 Dashboard 获取运行在集群中的应用的概览信息,也可以创建或者修改 Kubernetes 资源 (如 Deployment,Job,DaemonSet 等等)。 例如,你可以对 Deployment 实现弹性伸缩、发起滚动升级、重启 Pod 或者使用向导创建新的应用。

  • Dashboard 同时展示了 Kubernetes 集群中的资源状态信息和所有报错信息。

镜像和dashboard的yaml文件获取


  • 这是我自己下载的文件,包含下面所有用到的yaml文件和镜像【也可以继续往下看,自己下载的哈】

k8s-dashboard镜像和yaml文件.rar

在这里插入图片描述

  • dashboard的yaml文件我们可以去官网获取最新的,也可以看看官方的介绍,不管yaml文件是不是最新的,下面的方法都是一样的哈

部署 Dashboard UI

官网里面呢,有一个网址,这个就是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 ~]#

dashboard配置测试


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>

Kubernetes Dashboard

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]#

yaml文件中限制【resource字段限制】


作用: 用来限制每个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

如何自学黑客&网络安全

黑客零基础入门学习路线&规划

初级黑客
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、超级黑客
这部分内容对零基础的同学来说还比较遥远,就不展开细说了,附上学习路线。
img

网络安全工程师企业级学习路线

img
如图片过大被平台压缩导致看不清的话,评论区点赞和评论区留言获取吧。我都会回复的

视频配套资料&国内外网安书籍、文档&工具

当然除了有配套的视频,同时也为大家整理了各种文档和书籍资料&工具,并且已经帮大家分好类了。

img
一些笔者自己买的、其他平台白嫖不到的视频教程。
img

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

需要这份系统化资料的朋友,可以点击这里获取

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

  • 30
    点赞
  • 29
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值