【K8s】安全认证与DashBoard

最新推荐文章于 2024-07-13 16:17:48 发布
最新推荐文章于 2024-07-13 16:17:48 发布
阅读量844 收藏 18
点赞数 17
文章标签： kubernetes 安全 容器
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/m0_59598029/article/details/135914413
版权
文章目录
  • 一、概述
  • * 1、客户端
    • 2、认证、鉴权与准入控制
  • 二、认证管理
  • * 1、认证方式
    • 2、HTTPS证书认证
  • 三、授权管理
  • * 1、授权与RBAC
    • 2、Role 与 ClusterRole
    • 3、RoleBinding 与 ClusterRoleBinding
    • 4、案例：创建一个只能管理dev空间下Pods资源的账号
  • 四、准入控制
  • 五、DashBoard
  • * 1、部署DashBoard
    • 2、使用DashBoard

一、概述

Kubernetes作为一个分布式集群的管理工具，保证集群的安全性是必要的。安全性就是让所有的Kubernetes客户端以一个合法的身份和合法的步骤来访问我们的系统。

1、客户端

在Kubernetes集群中，客户端通常有两类：

  • User Account：一般是独立于kubernetes之外的其他服务管理的用户账号。
  • Service Account：kubernetes管理的账号，用于为Pod中的服务进程在访问Kubernetes时提供身份标识。

在这里插入图片描述

2、认证、鉴权与准入控制

ApiServer是访问及管理资源对象的唯一入口。而任何一个请求访问ApiServer，又都要经过下面三个流程：

  • Authentication（认证）：身份鉴别，只有正确的账号才能够通过认证
  • Authorization（授权）： 判断用户是否有权限对访问的资源执行特定的动作
  • Admission Control（准入控制）：用于补充授权机制以实现更加精细的访问控制功能。

在这里插入图片描述

二、认证管理

1、认证方式

Kubernetes集群识别并认证客户端身份有三种方式：

HTTP Base认证：通过用户名+密码的方式认证

把“用户名:密码”用BASE64算法进行编码后的字符串放在HTTP请求中的Header
Authorization域里发送给服务端。服务端解码后获取用户名及密码，然后进行用户身份认证。

HTTP Token认证：通过一个Token来识别合法用户

用一个很长的难以被模仿的字符串–Token来表明客户身份的一种方式。每个Token对应一个用户名，当客户端发起API调用请求时，需要在HTTP
Header里放入Token，API Server接到Token后会跟服务器中保存的token进行比对，然后进行用户身份认证的过程。

HTTPS证书认证：基于CA根证书签名的双向数字证书认证方式

安全性最高的一种方式，但是同时也是操作起来最麻烦的一种方式。

2、HTTPS证书认证

在这里插入图片描述

HTTPS认证大体分为3个过程：

STEP1：证书申请和下发

HTTPS通信双方的服务器向CA机构申请证书，CA机构下发根证书、服务端证书及私钥给申请者

STEP2：客户端和服务端的双向认证

  • 客户端向服务器端发起请求，服务端下发自己的证书给客户端

  • 客户端接收到证书后，通过私钥解密证书，在证书中获得服务端的公钥

  • 客户端利用服务器端的公钥认证证书中的信息，如果一致，则认可这个服务器

  • 客户端发送自己的证书给服务器端

  • 服务端接收到证书后，通过私钥解密证书，在证书中获得客户端的公钥

  • 服务端用该公钥认证证书信息，确认客户端是否合法

    STEP3：服务器端和客户端进行通信

  • 服务器端和客户端协商好加密方案后，客户端会产生一个随机的秘钥并加密，然后发送到服务器端

  • 服务器端接收这个秘钥后，双方接下来通信的所有内容都通过该随机秘钥加密

注意: Kubernetes允许同时配置多种认证方式，只要其中任意一个方式认证通过即可

三、授权管理

1、授权与RBAC

认证后就知道客户端是谁， 然后Kubernetes会根据事先定义的授权策略来判断用户是否有权限访问，即授权。

每个发送到ApiServer的请求都带上了用户和资源的信息：比如发送请求的用户、请求的路径、请求的动作等，授权就是根据这些信息和授权策略进行比较，如果符合策略，则认为授权通过，否则会返回错误。

API Server目前支持以下几种授权策略：

  • AlwaysDeny：表示拒绝所有请求，一般用于测试

  • AlwaysAllow：允许接收所有请求，相当于集群不需要授权流程（Kubernetes默认的策略）

  • ABAC：基于属性的访问控制，表示使用用户配置的授权规则对用户请求进行匹配和控制

  • Webhook：通过调用外部REST服务对用户进行授权

  • Node：是一种专用模式，用于对kubelet发出的请求进行访问控制

  • RBAC：基于角色的访问控制（kubeadm安装方式下的默认选项）

    RBAC(Role-Based Access Control) 基于角色的访问控制
    主要是在描述一件事情：给哪些对象授予了哪些权限

其中涉及到了下面几个概念：

  • 对象：User、Groups、ServiceAccount
  • 角色：代表着一组定义在资源上的可操作动作(权限)的集合
  • 绑定：将定义好的角色跟用户绑定在一起

在这里插入图片描述
RBAC引入了4个顶级资源对象：

  • Role、ClusterRole：角色，用于指定一组权限
  • RoleBinding、ClusterRoleBinding：角色绑定，用于将角色（权限）赋予给对象

2、Role 与 ClusterRole

一个角色就是一组权限的集合，这里的权限都是许可形式的（白名单）。

# Role只能对命名空间内的资源进行授权，需要指定nameapce
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: dev
  name: authorization-role
rules:
- apiGroups: [""]  # 支持的API组列表,"" 空字符串，表示核心API群
  resources: ["pods"] # 支持的资源对象列表
  verbs: ["get", "watch", "list"] # 允许的对资源对象的操作方法列表

注意，Role这种资源是namespace级别的，ClusterRole则是集群级别的：

# ClusterRole可以对集群范围内资源、跨namespaces的范围资源、非资源类型进行授权
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
 name: authorization-clusterrole
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

二者的rules中的参数：

  • apiGroups: 支持的API组列表

    “”,“apps”, “autoscaling”, “batch”

  • resources：支持的资源对象列表

    “services”, “endpoints”, “pods”,“secrets”,“configmaps”,“crontabs”,“deployments”,“jobs”,
    “nodes”,“rolebindings”,“clusterroles”,“daemonsets”,“replicasets”,“statefulsets”,
    “horizontalpodautoscalers”,“replicationcontrollers”,“cronjobs”

  • verbs：对资源对象的操作方法列表

    “get”, “list”, “watch”, “create”, “update”, “patch”, “delete”, “exec”

3、RoleBinding 与 ClusterRoleBinding

角色绑定用来把一个角色绑定到一个目标对象上，绑定目标可以是User、Group或者ServiceAccount

# RoleBinding可以将同一namespace中的subject绑定到某个Role下，则此subject即具有该Role定义的权限
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: authorization-role-binding
  namespace: dev
####注意这里
subjects:
- kind: User
  name: heima
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: authorization-role
  apiGroup: rbac.authorization.k8s.io



# ClusterRoleBinding在整个集群级别和所有namespaces将特定的subject与ClusterRole绑定，授予权限
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
 name: authorization-clusterrole-binding
subjects:
- kind: User
  name: heima
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: authorization-clusterrole
  apiGroup: rbac.authorization.k8s.io

和Role、ClusterRole对应，RoleBinding是namespace级别的，ClusterRoleBinding是集群级别的。但RoleBinding可以引用ClusterRole，对属于同一命名空间内ClusterRole定义的资源主体进行授权。

RoleBinding可以引用ClusterRole，对属于同一命名空间内ClusterRole定义的资源主体进行授权。

虽然authorization-clusterrole是一个集群角色，但是因为使用了RoleBinding，所以heima只能读取dev命名空间中的资源

# 虽然authorization-clusterrole是一个集群角色，但是因为使用了RoleBinding
# 所以heima只能读取dev命名空间中的资源
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: authorization-role-binding-ns
  namespace: dev
subjects:
- kind: User
  name: heima
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: authorization-clusterrole
  apiGroup: rbac.authorization.k8s.io

4、案例：创建一个只能管理dev空间下Pods资源的账号

我们使用admin，可以对所有namespace下的所有资源进行操作，接下来创建一个只能管理dev空间下Pods资源的账号：

  • 创建账号

    1) 创建证书

    [root@k8s-master01 pki] cd /etc/kubernetes/pki/
    [root@k8s-master01 pki] (umask 077;openssl genrsa -out devman.key 2048)

    2) 用apiserver的证书去签署

    2-1) 签名申请，申请的用户是devman,组是devgroup

    [root@k8s-master01 pki] openssl req -new -key devman.key -out devman.csr -subj “/CN=devman/O=devgroup”

    2-2) 签署证书

    [root@k8s-master01 pki] openssl x509 -req -in devman.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out devman.crt -days 3650

    3) 设置集群、用户、上下文信息

    [root@k8s-master01 pki] kubectl config set-cluster kubernetes --embed-certs=true --certificate-authority=/etc/kubernetes/pki/ca.crt --server=https://192.168.109.100:6443

    [root@k8s-master01 pki] kubectl config set-credentials devman --embed-certs=true --client-certificate=/etc/kubernetes/pki/devman.crt --client-key=/etc/kubernetes/pki/devman.key

    [root@k8s-master01 pki] kubectl config set-context devman@kubernetes --cluster=kubernetes --user=devman

  • 切换账户到devman

    [root@k8s-master01 pki] kubectl config use-context devman@kubernetes
    Switched to context “devman@kubernetes”.

    查看dev下pod，发现没有权限

    [root@k8s-master01 pki] kubectl get pods -n dev
    Error from server (Forbidden): pods is forbidden: User “devman” cannot list resource “pods” in API group “” in the namespace “dev”

    切换到admin账户

    [root@k8s-master01 pki] kubectl config use-context kubernetes-admin@kubernetes
    Switched to context “kubernetes-admin@kubernetes”.

  • 切回admin后，创建Role和RoleBinding，为devman用户授权

    kind: Role
    apiVersion: rbac.authorization.k8s.io/v1beta1
    metadata:
    namespace: dev
    name: dev-role
    rules:

    • apiGroups: [“”]
      resources: [“pods”]
      verbs: [“get”, “watch”, “list”] # 该角色，可以对dev空间下的核心API群的pod资源进行get、watch、list

    kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1beta1
    metadata:
    name: authorization-role-binding
    namespace: dev
    subjects:

    • kind: User
      name: devman
      apiGroup: rbac.authorization.k8s.io
      roleRef:
      kind: Role
      name: dev-role # 把dev-role角色绑定到了User.devman，devman就有了这个角色的权限
      apiGroup: rbac.authorization.k8s.io

    [root@k8s-master01 pki] kubectl create -f dev-role.yaml
    role.rbac.authorization.k8s.io/dev-role created
    rolebinding.rbac.authorization.k8s.io/authorization-role-binding created

  • 切回账户，再次验证

    切换账户到devman

    [root@k8s-master01 pki] kubectl config use-context devman@kubernetes
    Switched to context “devman@kubernetes”.

    再次查看，可以查看了

    根据角色的信息，查看deploy则仍然没有权限

    [root@k8s-master01 pki] kubectl get pods -n dev
    NAME READY STATUS RESTARTS AGE
    nginx-deployment-66cb59b984-8wp2k 1/1 Running 0 4d1h
    nginx-deployment-66cb59b984-dc46j 1/1 Running 0 4d1h
    nginx-deployment-66cb59b984-thfck 1/1 Running 0 4d1h

    为了不影响后面的测试,切回admin账户

    [root@k8s-master01 pki] kubectl config use-context kubernetes-admin@kubernetes
    Switched to context “kubernetes-admin@kubernetes”.

四、准入控制

认证+鉴权通过后，还要通过准入控制，apiserver才会处理这个请求。

准入控制是一个可配置的控制器列表，可以通过在Api-Server上通过命令行设置选择执行哪些准入控制器：

--admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,
                      DefaultStorageClass,ResourceQuota,DefaultTolerationSeconds

只有当所有的准入控制器都检查通过之后，apiserver才执行该请求，否则返回拒绝。

当前可配置的Admission Control准入控制如下：

  • 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的安全策略进行控制

五、DashBoard

除了敲命令行，也可以使用可视化面板来操作。（不过我还是觉得敲指令帅气！）

1、部署DashBoard

  • 下载yaml

    下载yaml

    [root@k8s-master01 ~] wget https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0/aio/deploy/recommended.yaml

    修改kubernetes-dashboard的Service类型，改为NodePort类型Service，并开nodePort，方便我们在集群外（本机浏览器）访问

    kind: Service
    apiVersion: v1
    metadata:
    labels:
    k8s-app: kubernetes-dashboard
    name: kubernetes-dashboard
    namespace: kubernetes-dashboard
    spec:
    type: NodePort # 新增
    ports:
    - port: 443
    targetPort: 8443
    nodePort: 30009 # 新增
    selector:
    k8s-app: kubernetes-dashboard

  • 创建Dashboard资源

    部署

    [root@k8s-master01 ~] kubectl create -f recommended.yaml

    查看namespace下的kubernetes-dashboard下的资源

    [root@k8s-master01 ~] kubectl get pod,svc -n kubernetes-dashboard
    NAME READY STATUS RESTARTS AGE
    pod/dashboard-metrics-scraper-c79c65bb7-zwfvw 1/1 Running 0 111s
    pod/kubernetes-dashboard-56484d4c5-z95z5 1/1 Running 0 111s

    NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
    service/dashboard-metrics-scraper ClusterIP 10.96.89.218 8000/TCP 111s
    service/kubernetes-dashboard NodePort 10.104.178.171 443:30009/TCP 111s

  • 此时访问nodeIp:port就可以进入登录页面，https://节点IP:30009
    在这里插入图片描述

  • 创建访问账户，获取token

    创建账号

    [root@k8s-master01-1 ~] kubectl create serviceaccount dashboard-admin -n kubernetes-dashboard

    授权

    –clusterrole=cluster-admin 指定绑定关系中的角色

    –serviceaccount=kubernetes-dashboard:dashboard-admin指定绑定关系中的某个namespace下的用户

    [root@k8s-master01-1 ~] kubectl create clusterrolebinding dashboard-admin-rb --clusterrole=cluster-admin --serviceaccount=kubernetes-dashboard:dashboard-admin

    获取账号token

    [root@k8s-master01 ~] kubectl get secrets -n kubernetes-dashboard | grep dashboard-admin
    dashboard-admin-token-xbqhh kubernetes.io/service-account-token 3 2m35s

    [root@k8s-master01 ~] kubectl describe secrets dashboard-admin-token-xbqhh -n kubernetes-dashboard
    Name: dashboard-admin-token-xbqhh
    Namespace: kubernetes-dashboard
    Labels:
    Annotations: kubernetes.io/service-account.name: dashboard-admin
    kubernetes.io/service-account.uid: 95d84d80-be7a-4d10-a2e0-68f90222d039

    Type: kubernetes.io/service-account-token

    Data

    namespace: 20 bytes
    token: eyJhbGciOiJSUzI1NiIsImtpZCI6ImJrYkF4bW5XcDhWcmNGUGJtek5NODFuSXl1aWptMmU2M3o4LTY5a2FKS2cifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlcm5ldGVzLWRhc2hib2FyZCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJkYXNoYm9hcmQtYWRtaW4tdG9rZW4teGJxaGgiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiZGFzaGJvYXJkLWFkbWluIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQudWlkIjoiOTVkODRkODAtYmU3YS00ZDEwLWEyZTAtNjhmOTAyMjJkMDM5Iiwic3ViIjoic3lzdGVtOnNlcnZpY2VhY2NvdW50Omt1YmVybmV0ZXMtZGFzaGJvYXJkOmRhc2hib2FyZC1hZG1pbiJ9.NAl7e8ZfWWdDoPxkqzJzTB46sK9E8iuJYnUI9vnBaY3Jts7T1g1msjsBnbxzQSYgAG–cV0WYxjndzJY_UWCwaGPrQrt_GunxmOK9AUnzURqm55GR2RXIZtjsWVP2EBatsDgHRmuUbQvTFOvdJB4x3nXcYLN2opAaMqg3rnU2rr-A8zCrIuX_eca12wIp_QiuP3SF-tzpdLpsyRfegTJZl6YnSGyaVkC9id-cxZRb307qdCfXPfCHR_2rt5FVfxARgg_C0e3eFHaaYQO7CitxsnIoIXpOFNAR8aUrmopJyODQIPqBWUehb7FhlU1DCduHnIIXVC_UICZ-MKYewBDLw
    ca.crt: 1025 bytes

  • 在登录页面上输入上面的token就可登录成功
    在这里插入图片描述
    在这里插入图片描述

2、使用DashBoard

查看

选择指定的命名空间dev，然后点击Deployments，查看dev空间下的所有deployment
在这里插入图片描述

扩缩容

在Deployment上点击规模，然后指定目标副本数量，点击确定

在这里插入图片描述

编辑

在Deployment上点击编辑，然后修改yaml文件，点击确定

在这里插入图片描述

查看Pod

点击Pods, 查看pods列表

在这里插入图片描述

操作Pod

选中某个Pod，可以对其执行日志（logs）、进入执行（exec）、编辑、删除操作

题外话

初入计算机行业的人或者大学计算机相关专业毕业生，很多因缺少实战经验，就业处处碰壁。下面我们来看两组数据：

2023届全国高校毕业生预计达到1158万人，就业形势严峻；

国家网络安全宣传周公布的数据显示，到2027年我国网络安全人员缺口将达327万。

一方面是每年应届毕业生就业形势严峻，一方面是网络安全人才百万缺口。

6月9日，麦可思研究2023年版就业蓝皮书（包括《2023年中国本科生就业报告》《2023年中国高职生就业报告》）正式发布。

2022届大学毕业生月收入较高的前10个专业

本科计算机类、高职自动化类专业月收入较高。2022届本科计算机类、高职自动化类专业月收入分别为6863元、5339元。其中，本科计算机类专业起薪与2021届基本持平，高职自动化类月收入增长明显，2022届反超铁道运输类专业（5295元）排在第一位。

具体看专业，2022届本科月收入较高的专业是信息安全（7579元）。对比2018届，电子科学与技术、自动化等与人工智能相关的本科专业表现不俗，较五年前起薪涨幅均达到了19%。数据科学与大数据技术虽是近年新增专业但表现亮眼，已跻身2022届本科毕业生毕业半年后月收入较高专业前三。五年前唯一进入本科高薪榜前10的人文社科类专业——法语已退出前10之列。

“没有网络安全就没有国家安全”。当前，网络安全已被提升到国家战略的高度，成为影响国家安全、社会稳定至关重要的因素之一。

网络安全行业特点

1、就业薪资非常高，涨薪快 2022年猎聘网发布网络安全行业就业薪资行业最高人均33.77万！

img

2、人才缺口大，就业机会多

2019年9月18日《中华人民共和国中央人民政府》官方网站发表：我国网络空间安全人才 需求140万人，而全国各大学校每年培养的人员不到1.5W人。猎聘网《2021年上半年网络安全报告》预测2027年网安人才需求300W，现在从事网络安全行业的从业人员只有10W人。
img

行业发展空间大，岗位非常多

网络安全行业产业以来，随即新增加了几十个网络安全行业岗位︰网络安全专家、网络安全分析师、安全咨询师、网络安全工程师、安全架构师、安全运维工程师、渗透工程师、信息安全管理员、数据安全工程师、网络安全运营工程师、网络安全应急响应工程师、数据鉴定师、网络安全产品经理、网络安全服务工程师、网络安全培训师、网络安全审计员、威胁情报分析工程师、灾难恢复专业人员、实战攻防专业人员…

职业增值潜力大

网络安全专业具有很强的技术特性，尤其是掌握工作中的核心网络架构、安全技术，在职业发展上具有不可替代的竞争优势。

随着个人能力的不断提升，所从事工作的职业价值也会随着自身经验的丰富以及项目运作的成熟，升值空间一路看涨，这也是为什么受大家欢迎的主要原因。

从某种程度来讲，在网络安全领域，跟医生职业一样，越老越吃香，因为技术愈加成熟，自然工作会受到重视，升职加薪则是水到渠成之事。

黑客&网络安全如何学习

今天只要你给我的文章点赞，我私藏的网安学习资料一样免费共享给你们，来看看有哪些东西。

1.学习路线图

行业发展空间大，岗位非常多

网络安全行业产业以来，随即新增加了几十个网络安全行业岗位︰网络安全专家、网络安全分析师、安全咨询师、网络安全工程师、安全架构师、安全运维工程师、渗透工程师、信息安全管理员、数据安全工程师、网络安全运营工程师、网络安全应急响应工程师、数据鉴定师、网络安全产品经理、网络安全服务工程师、网络安全培训师、网络安全审计员、威胁情报分析工程师、灾难恢复专业人员、实战攻防专业人员…

职业增值潜力大

网络安全专业具有很强的技术特性，尤其是掌握工作中的核心网络架构、安全技术，在职业发展上具有不可替代的竞争优势。

随着个人能力的不断提升，所从事工作的职业价值也会随着自身经验的丰富以及项目运作的成熟，升值空间一路看涨，这也是为什么受大家欢迎的主要原因。

从某种程度来讲，在网络安全领域，跟医生职业一样，越老越吃香，因为技术愈加成熟，自然工作会受到重视，升职加薪则是水到渠成之事。

黑客&网络安全如何学习

今天只要你给我的文章点赞，我私藏的网安学习资料一样免费共享给你们，来看看有哪些东西。

1.学习路线图

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

攻击和防守要学的东西也不少，具体要学的东西我都写在了上面的路线图，如果你能学完它们，你去就业和接私活完全没有问题。

2.视频教程

网上虽然也有很多的学习资源，但基本上都残缺不全的，这是我自己录的网安视频教程，上面路线图的每一个知识点，我都有配套的视频讲解。

内容涵盖了网络安全法学习、网络安全运营等保测评、渗透测试基础、漏洞详解、计算机基础知识等，都是网络安全入门必知必会的学习内容。

3.技术文档和电子书

技术文档也是我自己整理的，包括我参加大型网安行动、CTF和挖SRC漏洞的经验和技术要点，电子书也有200多本，由于内容的敏感性，我就不一一展示了。

4.工具包、面试题和源码

“工欲善其事必先利其器”我为大家总结出了最受欢迎的几十款款黑客工具。涉及范围主要集中在 信息收集、Android黑客工具、自动化工具、网络钓鱼等，感兴趣的同学不容错过。

还有我视频里讲的案例源码和对应的工具包，需要的话也可以拿走。

这些题目都是大家在面试深信服、奇安信、腾讯或者其它大厂面试时经常遇到的，如果大家有好的题目或者好的见解欢迎分享。

参考解析：深信服官网、奇安信官网、Freebuf、csdn等

内容特点：条理清晰，含图像化表示更加易懂。

内容概要：包括 内网、操作系统、协议、渗透测试、安服、漏洞、注入、XSS、CSRF、SSRF、文件上传、文件下载、文件包含、XXE、逻辑漏洞、工具、SQLmap、NMAP、BP、MSF…

img

因篇幅有限，仅展示部分资料，需要点击下方链接即可前往获取

如果你对网络安全入门感兴趣，那么你需要的话可以点击这里👉网络安全重磅福利：入门&进阶全套282G学习资源包免费分享！

教IT的小强
关注
  • 17
    点赞
  • 踩
  • 18
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
k8s-安装dashboard
河静
08-10 475
k8s-安装dashboard 1.下载recommended.yaml vi /etc/hosts 添加如下内容： # GitHub Start 192.30.253.112 github.com 192.30.253.119 gist.github.com 151.101.100.133 assets-cdn.github.com 151.101.100.133 raw.githubusercontent.com 151.101.100.133 gist.githubusercontent.c
K8S安装Dashboard
ywmack
05-09 1034
部署：kubernetes-dashboard 这个镜像在部署的时候down下来如果没有可以执行下面脚本。包含了kubernetes-dashboard wget https://raw.githubusercontent.com/ywmack/k8s/master/down-node-images.sh chmod 755 down-node-images.sh /bin/bash down-n...
K8S 安全认证
elihe2011的专栏
12-27 3944
1. 安全机制 1.1 认证 (Authentication) 1.1.1 认证方式 HTTP Token：Authorization: Bearer $TOKEN HTTP Basic： Authorization: Basic $(base64encode USERNAME:PASSWORD), HTTPS: 基于CA根证书签名的客户端身份认证方式（推荐） 证书颁发： 手动签发：通过k8s集群的根 ca 进行签发 HTTPS 证书 自动签发：kubelet 首次访问 API Serv
Kubernetes Dashboard部署安装
lpfstudy的博客
07-17 7387
创建dashboard成功！跟grafana差不多。
测试人必会 K8S 操作之 Dashboard
最新发布
人生不怕起点低，就怕没追求
07-13 495
Kubernetes Dashboard 是管理 Kubernetes 集群的一个强大工具，提供了直观的 UI 和丰富的功能，帮助用户高效地管理和监控集群。有效帮助用户查看、创建、更新和删除各种 Kubernetes 资源，是测试开发管理K8S的有效平台工具
K8s-k8s集群部署-8-部署Dashboard
little_startoo的博客
01-30 1956
K8s-k8s集群部署-8-部署Dashboard
k8s dashboard安装部署实战详细手册
少说，多做
11-25 6746
k8s采用的是基于角色的访问控制策略，Role-Based Access Control, 即”RBAC”，使用”rbac.authorization.k8s.io” API Group实现授权决策，涉及到ServiceAccount，Role，ClusterRole，RoleBinding，ClusterRoleBinding，Secret等概念。复制最后的token字符串到登录界面，点击登录，可以看到dashboard首页。k8s提供两种登录机制，本文采用Token访问机制进行登录。
【3】k8s搭建DashBoard
强哥的微博
01-13 2792
k8s搭建dashboard，成功搭建图像化界面
k8s dashboard
05-30
### k8s Dashboard 操作手册知识点详解 #### 一、Kubernetes Dashboard 简介 Kubernetes Dashboard 是 Kubernetes 的官方 Web UI，它提供了图形化的界面来管理 Kubernetes 集群中的资源，包括部署、复制集、Pods 等...
k8s-dashboardv2.0.3.zip
10-08
安装 Kubernetes Dashboard 时，通常会使用 `kubectl apply -f` 命令逐一应用这些 YAML 文件，按照部署、权限、配置和认证的顺序，确保 Dashboard 可以安全地运行并正确地与集群交互。一旦部署完成，用户可以通过...
5-k8s部署之Dashboard1
08-08
5. **安全性与最佳实践** - 虽然 `cluster-admin` 角色提供了极大便利，但过度授权可能带来安全风险。生产环境中，应考虑使用更细粒度的 RBAC 规则，仅授予 Dashboard 执行必要操作的权限。 - 考虑使用 ingress ...
k8s kubernetes dashboard dns 配置文件 yaml
06-26
在Kubernetes（k8s）集群环境中，配置和管理各个组件是系统运维的关键部分。这里我们聚焦于Kubernetes Dashboard、DNS服务以及相关的YAML配置文件。YAML是一种常用的语言，用于编写Kubernetes的资源定义，它简洁且...
k8s培训视频.zip
05-09
目录网盘文件永久链接 01-Devops核心要点及kubernetes架构概述 02-kubernetes基础概念 ...17-kubernetes dashboard认证及分级授权 18-配置网络插件flannel 19-基于canel的网络策略 20-调度器、预选策略及优选函数 ...
K8s（kubernetes）集群搭建及dashboard安装、基础应用部署
Ricardo.M.Yu的博客
07-12 2008
本质是一组服务器集群，在集群每个节点上运行特定的程序，来对节点中的容器进行管理。实现资源管理的自动化。
k8s安全认证
杨海吉
01-31 495
Kubernetes作为一个分布式集群的管理工具，保证集群的安全性是其一个重要的任务。所谓的安全性其实就是保证对Kubernetes的各种客户端进行认证和鉴权操作。客户端：一般是独立于kubernetes之外的其他服务管理的用户账号。：kubernetes管理的账号，用于为Pod中的服务进程在访问Kubernetes时提供身份标识。认证、授权与准入控制ApiServer是访问及管理资源对象的唯一入口。Authentication（认证）：身份鉴别，只有正确的账号才能够通过认证。
k8s部署Dashboard
chanyue123的博客
04-12 1089
k8s部署Dashboard
学习笔记十二：安装k8s可视化UI界面dashboard
weixin_43258559的博客
03-29 2230
port是集群内的pod互相通信用的端口类型，比如nginx访问mysql，而mysql是不需要让客户访问到的，port是service的的端口。在google浏览器中，在上图出现的页面任意位置，直接键盘敲入这11个字符：thisisunsafe，可以直接跳过安全报错进入页面。注：表单中创建pod时没有创建nodeport的选项，会自动创建在30000+以上的端口。nodeport是集群外流量访问集群内服务的端口，比如客户访问nginx，apache，打开kubernetes的dashboard界面。
k8s部署dashboard
ApexPredator的博客
05-22 743
k8s部署dashboard
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值