Kubernetes 权限管理认证鉴权详解

目录
  • 正文
  • 认证
    • 认证用户
      • Normal Users
      • Service Accounts
    • 认证策略
      • 客户端证书
      • 不记名令牌
      • Static Token File
      • Service Account Tokens
      • OpenID Connect Tokens
  • 鉴权
    • 鉴权流程
    • 鉴权模块
      • RBAC
      • Role 和 ClusterRole
      • RoleBinding 和 ClusterRoleBinding
      • Service Account
  • 最后

正文

Kubernetes 主要通过 API Server 对外提供服务,对于这样的系统来说,如果不加以安全限制,那么可能导致请求被滥用,甚至导致整个集群崩塌。

鉴于此,Kubernetes 对于访问 API 的用户提供了相应的安全控制:认证和授权。认证解决用户是谁的问题,授权解决用户能做什么的问题。只有通过合理的权限控制,才能够保证整个集群系统的安全可靠。

下图是 API 访问需要经过的三个步骤,它们分别是:认证、授权和准入,准入不在这章节讨论,它更多专注的是资源的管理。

认证

认证(Authentication)是指用户是否可以登录 Kubernetes,即是否可以向 API Server 发送请求。

在 Kubernetes 中,有两类用户:

  • Normal Users:外部用户
  • Service Accounts:内部用户

认证用户

Normal Users

Normal Users 独立于 Kubernetes,不归其管理,这类用户可以是:

  • 可以分发 private keys 的管理员(真人)
  • 提供用户服务的第三方厂商,比如 Google Accounts
  • 保存用户名和密码的列表文件

如果用户都不在 Kubernetes 中,都不归它管,那它是如何进行认证的呢?

对于一般的应用系统来说,用户提供用户名和密码,服务端收到过后会在数据库中进行检查是否存在并有效,如果有就表示鉴权成功,反之失败。

那对于 Kubernetes 来说,是如何实现的呢?

尽管无法通过 API 调用来添加普通用户,Kubernetes 巧妙的通过证书来进行用户认证。也就是说,不管任何用户,只要能提供有效的证书就能通过 Kubernetes 用户认证。

通过用户认证过后,Kubernetes 会把证书中的 CN 作为用户名(比如证书中”/CN=joker“,则用户名就是 Joker),把 Organization 作为用户组,然后由用户名和用户组绑定的 Role 来决定用户的权限。

Service Accounts

Service Accounts 由 Kubernetes 管理,它们被绑定到特定的 namespace,其可以通过 API Server 自己创建,也可以通过调用 API 来创建,比如使用 kubectl 客户端工具。

与 Normal Users 不同,Service Accounts 存在对应的 Kubernetes 对象,当创建 Service Accounts,会创建相应的 Secret,里面保存对应的密码信息(在 1.24.x 版本中,不会创建对应的 secret)。当创建的 Pod 指定了一个 Service Account,其 Secret 会被 Mount 到 Pod 中,Pod 中的进程就可以访问 Kubernetes API 了。

认证策略

Kubernetes 有以下几种鉴权方法:

  • 客户端证书
  • 不记名令牌
  • 身份认证代理
  • 通过鉴权插件的 HTTP 基本认证机制

当 HTTP 请求发送到 API Server 时,Kubernetes 会从 Request 中关联以下信息:

  • Username:用户名,用来辨识最终用户的字符串,比如 kube-admin 或jane@example.com
  • UID:用户 ID,代表用户的唯一 ID
  • Groups:用户组,代表逻辑相关的一组用户,
  • Extra Fields,扩展字段,鉴权可能需要的其他信息

需要注意的是,当多种鉴权方法同时启用时,第一个鉴权方法鉴权成功即通过验证,其它方法不再鉴权,同时 api-server 也不保证鉴权方法的顺序。所有鉴权成功的用户都会加到 group “system:authenticated”中。

客户端证书

当我们使用客户端证书进进行认证时,需要向 Kubernetes 提供有效的证书,这个证书可以是外部证书,也可以是 Kubernetes 自己审批的证书。

如果是外部证书,就需要在 API Server 启动的时候用--client-ca-file=SOMEFILE参数引入外部证书的 CA 等信息,用来验证客户端证书的有效性。

当认证通过后,Kubernetes 会把证书的 Subject CN 作为用户名,Organization 作为用户组(Group)。

不记名令牌

当使用不记名令牌(Bearer token)来对某 HTTP 客户端执行身份认证时,API 服务器希望看到一个名为 Authorization 的 HTTP 头,其值格式为 Bearer。不记名令牌(Bearer token)必须是一个可以放入 HTTP 头部值字段的字符序列,至多可使用 HTTP 的编码和引用机制。例如:如果持有者令牌为 31ada4fd-adec-460c-809a-9e56ceb75269,则其出现在 HTTP 头部时如下所示:

Authorization: Bearer 31ada4fd-adec-460c-809a-9e56ceb75269

在 Kubernetes 中,主要有以下几种使用不记名令牌(Bearer token)的方法:

  • Static Token File(静态令牌)
  • Service Account Tokens(服务账号令牌)
  • OpenID Connect Tokens(OIDC 令牌)

Static Token File

当使用静态令牌的时候,API Server 会通过--token-auth-file=SOMEFILE从外部引入一个 CSV 文件,API Server 会从这个文件中读取对应的用户名和用户组。

当客户端进行请求时,API Server 把请求 Header 中的 Bearer tokens 和文件中的 token 进行比较,然后判断 Token 是否有效。

Service Account Tokens

当手动或者自动创建 Service Account 的时候,Kubernetes 会自动创建一个 Service Account Token,在 v1.24 版本之前,会对应创建一个 secret 保存到对应的 namespace 中,在 v1.24 版本之后不会再单独创建 secret,而是在启动 Pod 的时候,由 kubelet 通过 TokenRequest API 生成一个 Token 挂载到 Pod 中。

上文提到,Service Account 主要是为 Pods 提供访问 API Server 的功能,当 Pod 创建过后,Service Account Token 就会被 Mount 到 Pod 中,此时 Pod 就拥有访问 API Server 的能力。

当然,Service Account Token 除了用在 Pod 上,在外部也可以使用,在《Kubernetes 集群管理》中的集群安装章节,有介绍使用 Token 访问 Kubernetes Dashboard,这时候使用的也是 Service Account Token。

OpenID Connect Tokens

OpenID Connect 是一种 OAuth3 认证方式,Kubernetes 可以利用 OAuth3 Token Response 中的 ID Token 作为 Bearer Token 进行认证访问。

其流程如下:

  • 登录到你的身份服务(Identity Provider)
  • 你的身份服务将为你提供 access_token、id_token 和 refresh_token
  • 在使用 kubectl 时,将 id_token 设置为 --token 标志值,或者将其直接添加到 kubeconfig 中
  • kubectl 将你的 id_token 放到一个称作 Authorization 的头部,发送给 API 服务器
  • API 服务器将负责通过检查配置中引用的证书来确认 JWT 的签名是合法的
  • 检查确认 id_token 尚未过期
  • 确认用户有权限执行操作
  • 鉴权成功之后,API 服务器向 kubectl 返回响应
  • kubectl 向用户提供反馈信息

不管用户通过哪种方式进行认证,认证通过并不代表就有操作权限,仅仅只是通过第一条防线而已,下一步就要进行鉴权,用来决定用户是否有具体的操作权限。

鉴权

鉴权流程

当请求通过认证(Authentication)过后,就会进入鉴权(Authorization)阶段。在这个阶段 Kubernetes 会检查请求是否有权限访问需要的资源,如果有权限则开始处理请求,反之则返回权限不足。

API Server 会检查所有 Policy 来检查是否存在 Policy 允许请求中的动作,存在则允许请求执行,否则会拒绝执行并返回 403 错误。当配置了多个授权模块的时候,请求会按顺序校验每一个模板,如果其中任一模块校验不通过,则请求会被拒绝,不再进行后续的校验。

Kubernetes 在做鉴权时,主要检查以下信息:

  • user:同鉴权中检查的信息相同
  • group:同鉴权中检查的信息相同
  • extra:同鉴权中检查的信息相同
  • API:是否为 Api 资源
  • Request path:非资源(API 资源)endpoint,比如/healthz
  • API request verb:API 动作,比如 get, list, create, update, patch,对某个资源的具体动作,比如,列出所有的 pod
  • HTTP request verb:用于非资源的请求中的 HTTP 动作,比如 get, post, put
  • Resource:请求访问的资源名字或 ID
  • Subresource:请求访问的子资源名字或 ID
  • Namespace:资源所在的名字空间
  • API group:请求访问的 API group,API group 指控制相关资源的一组 Api,如果未指定则代表 core API group

鉴权模块

Kubernetes 提供了以下 4 种鉴权模式:

  • Node:一种特殊的授权模块,基于 Node 上运行的 Pod 为 Kubelet 授权
  • ABAC:基于属性的访问控制
  • RBAC:基于角色的访问控制
  • Webhook:HTTP 请求回调,通过一个 WEB 应用鉴定是否有权限进行某项操作

这里只会介绍 RBAC——基于角色的访问控制。在实际中,这种模式使用的场景比较多。

RBAC

RBAC 是 Kubernetes 中常用的鉴权模式,其基本概念如下:

  • Rule:规则,一组属于不同 API Group 的操作集合;
  • Role:角色,用于定义一组对 Kubernetes API 对象操作的一组规则,作用于当个 namespace;
  • ClusterRole:集群角色,该角色不受 namespace 的限制;
  • Subject:被作用者,也就是规则作用的对象;
  • RoleBinding:将角色和被作用者进行绑定,作用于当个 namespace;
  • ClusterRoleBinding:将集群角色和作用者进行绑定,不受 namespace 限制;

Role 和 ClusterRole

Role 和 ClusterRole 中定义一组相关权限的规则,这些权限是累加的(不存在拒绝某操作的规则)。其中 Role 是 Namespace 级别的,而 ClusterRole 是集群级别的。

Role 的定义如下:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: role-demo
  namespace: devops
rules:
- apiGroups: [""]
  resources: ["pods", "deployment"]
  verbs: ["creat", "delete", "watch", "list", "get"]

其含义是:它允许被作用者在 devops 的 namespace 中对 pod 和 deployment 有 creat,delete,watch,list,get 操作。由于 Role 是 Namespace 级别,所以上面的规则只对 devops 的 namespace 有效。

ClusterRole 的定义如下:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-role-demo
rules:
- apiGroups: [""]
  resources: [""]
  verbs: ["watch", "list", "get"]

其含义是对所有资源都有 watch、list、get 的操作权限。

如果要定义所有权限,可以将 verbs 字段定义如下:

verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

RoleBinding 和 ClusterRoleBinding

角色绑定将一个角色中定义的各种权限授予一个或者一组用户。角色绑定包含了一组相关主体(即 subject, 包括用户——User、用户组——Group、或者服务账户——Service Account)以及对被授予角色的引用。在命名空间中可以通过 RoleBinding 对象授予权限,而集群范围的权限授予则通过 ClusterRoleBinding 对象完成。

RoleBinding 可以引用在同一命名空间内定义的 Role 对象。如下:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: joker-rolebinding
  namespace: devops
subjects:
  - kind: User
    name: joker
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: role-demo
  apiGroup: rbac.authorization.k8s.io

这就给 joker 用户和 role-demo 的 Role 建立了绑定关系,其中 joker 这个 User 只是一个授权系统中的逻辑概念,它需要通过外部认证服务,比如 Keystone,或者直接给 API Server 指定一个用户名,密码文件。

上面的 YAML 文件中其中一个重要的字段是 Subjects 字段,它定义"被作用者",其中的 kind 表示被作用者的类型,其有以下三种类型:

  • User:用户,这是由外部独立服务进行管理的,管理员进行私钥的分配,用户可以使用 KeyStone 或者 Goolge 帐号,甚至一个用户名和密码的文件列表,对于用户的管理集群内部没有一个关联的资源对象,所以用户不能通过集群内部的 API 来进行管理。
  • Group:组,这是用来关联多个账户,集群中有一个默认的组,比如 cluster-admin。
  • ServiceAccount:服务帐号,通过 Kubernetes API 来管理的一些用户帐号,和 namespace 进行关联的,适用于集群内部运行的应用程序,需要通过 API 来完成权限认证,所以在集群内部进行权限操作,我们都需要使用到 ServiceAccount。

另外一个重要字段是 roleRef,它定义 RoleBing 对象可以直接通过 Role 的名字来引用我们定义的 Role 对象,从而定义被作业者和角色之间的绑定关系。

RoleBinding 是 namespace 级别的,如果是集群级别则用 ClusterRoleBinding,如下:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: joker-clusterrolebinding
subjects:
  - kind: User
    name: joker
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-role-demo
  apiGroup: rbac.authorization.k8s.io

上面定义的就是 joker 这个用户对所有 namespace 里的资源都有 watch,list,get 的操作权限。

Service Account

Service Account 也是一种账号,但它并不是给 Kubernetes 集群的用户(系统管理员、运维人员、租户用户等)用的,而是给运行在 Pod 里的进程用的,它为 Pod 里的进程提供了必要的身份证明。

我们通过一个例子来了解 ServiceAccount 的授权过程。

1、首先定义一个 ServiceAccount:

apiVersion: v1
kind: ServiceAccount
metadata:
  namespace: devops
  name: sa-demo

一个简单的 ServiceAccount 只需要简单的 namespace 和 name 即可。

2、编写 RoleBinding 的 YAML 文件来为这个 ServiceAccount 分配权限:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: role-demo
  namespace: devops
rules:
  - apiGroups: [""]
    resources: ["pods", "deployment"]
    verbs: ["creat", "delete", "watch", "list", "get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: sa-rolebinding
  namespace: devops
subjects:
  - kind: ServiceAccount
    name: sa-demo
    namespace: devops
roleRef:
  kind: Role
  name: role-demo
  apiGroup: rbac.authorization.k8s.io

然后我们创建上面定义的 YAML 文件,查看创建完成后的信息:

$ kubectl get sa -n devops
NAME      SECRETS   AGE
default   0         6m25s
sa-demo   0         6m25s
$ kubectl get role -n devops
NAME        CREATED AT
role-demo   2022-07-06T04:27:02Z
$ kubectl get rolebinding -n devops
NAME             ROLE             AGE
sa-rolebinding   Role/role-demo   6m50s

现在创建一个 Pod 并使用 sa-demo Service Account。

apiVersion: v1
kind: Pod
metadata:
  name: pod-sa-demo
  namespace: devops
spec:
  serviceAccountName: sa-demo
  containers:
  - name: pod-sa-demo
    image: nginx
    imagePullPolicy: IfNotPresent

查看 Pod 信息如下:

$ kubectl get po -n devops pod-sa-demo -oyaml
apiVersion: v1
kind: Pod
metadata:
  annotations:
    cni.projectcalico.org/containerID: c0820de4319bb6915602c84132ff83a63f62abaa1e9c706bad04e64661455d30
    cni.projectcalico.org/podIP: 172.16.51.225/32
    cni.projectcalico.org/podIPs: 172.16.51.225/32
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{},"name":"pod-sa-demo","namespace":"devops"},"spec":{"containers":[{"image":"nginx","imagePullPolicy":"IfNotPresent","name":"pod-sa-demo"}],"serviceAccountName":"sa-demo"}}
  creationTimestamp: "2022-07-06T04:30:13Z"
  name: pod-sa-demo
  namespace: devops
  resourceVersion: "192831"
  uid: 4f4c7c5a-53ca-45f7-94ad-63e546cfcc62
spec:
  containers:
  - image: nginx
    imagePullPolicy: IfNotPresent
    name: pod-sa-demo
    resources: {}
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-vxrcd
      readOnly: true
  dnsPolicy: ClusterFirst
  enableServiceLinks: true
  nodeName: kk-node01
  preemptionPolicy: PreemptLowerPriority
  priority: 0
  restartPolicy: Always
  schedulerName: default-scheduler
  securityContext: {}
  serviceAccount: sa-demo
  serviceAccountName: sa-demo
  terminationGracePeriodSeconds: 30
  tolerations:
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  volumes:
  - name: kube-api-access-vxrcd
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          expirationSeconds: 3607
          path: token
      - configMap:
          items:
          - key: ca.crt
            path: ca.crt
          name: kube-root-ca.crt
      - downwardAPI:
          items:
          - fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
            path: namespace

从上面可以看到 Service Account Token 被挂载到 Pod 中了。

$ kubectl exec -it -n devops pod-sa-demo -- /bin/sh
# ls /var/run/secrets/kubernetes.io/serviceaccount
ca.crt  namespace  token

其中 ca,crt 就是用来访问 API Server 的。

如果一个 Pod 在定义时没有指定 spec.serviceAccountName 属性,则系统会自动为其赋值为 default,即大家都使用同一个 Namespace 下的默认 Service Account。

Subjects 的 kind 类型除了 User,ServiceAccount 之外,还有一个 Group,就是一组用户的意思。如果你为 Kubernetes 配置了外部认证服务的话,这个用户组就由外部认证服务提供。而对于 Kubernetes 内置用户 ServiceAccount 来说,其也有用户和用户组的概念,其中对于一个 ServiceAccount,其在 Kubernetes 中对应的用户是:

system:serviceaccount:<ServiceAccount名字>

而对于其用户组是:

system:serviceaccounts:<Namespace名字>

比如我们定义下面这个 RoleBinding:

subjects:
  - kind: Group
    name: system:serviceaccounts:devops
    apiGroup: rbac.authorization.k8s.io

这就意味着 Role 这个角色的权限规则作用与 devops 的 namespace 中的所有 ServiceAccount。

再比如:

subjects:
  - kind: Group
    name: system:serviceaccounts
    apiGroup: rbac.authorization.k8s.io

这就意味着 Role 这个角色规则作用与整个集群的所有 ServiceAccount。

kubernetes 已经内置了许多 ClusterRole,以 system:开头,可以用 kubectl get clusterrole 查看。

另外,Kubernetes 还提供了四个预先定义好的 ClusterRole 来供用户直接使用,它们是:

  • cluster-admin:超管
  • admin:普通管理权限
  • edit:修改权限
  • view:只读权限

我们在定义 RoleBinding 或 ClusterRolebinding 的时候可以直接使用。

最后

Kubernetes 的权限管理就介绍到这里,本章节主要介绍了认证、授权的大概流程以及在 Kubernetes 中是如何实现认证、授权的。学完本章,你可以掌握认证用户有哪些,有哪些认证策略,以及如何使用 RBAC 实现鉴权。

以上就是Kubernetes 权限管理认证鉴权详解的详细内容,更多关于Kubernetes 权限管理的资料请关注我们其它相关文章!

(0)

相关推荐

  • Google Kubernetes Engine 集群实战详解

    目录 GKE 集群介绍 K8s 带来的好处 使用 GKE 编排集群 GKE 集群介绍 Google Kubernetes Engine (GKE) 集群由 Kubernetes 开源集群管理系统提供支持.Kubernetes 为用户提供了与容器集群进行交互的机制.您可以使用 Kubernetes 命令和资源来部署和管理应用.执行管理任务.设置政策,以及监控您部署的工作负载的运行状况. K8s 带来的好处 自动管理 对应用容器进行监控和活跃性探测 自动扩缩 滚动更新 Google Cloud 上的

  • Kubernetes集群模拟删除k8s重装详解

    目录 一.系统环境 二.前言 三.重装Kubernetes集群 3.1 环境介绍 3.2 删除k8s所有节点(node) 3.3 kubeadm初始化 3.4 添加worker节点到k8s集群 3.5 安装calico 一.系统环境 服务器版本 docker软件版本 CPU架构 CentOS Linux release 7.4.1708 (Core) Docker version 20.10.12 x86_64 二.前言 当我们安装部署好一套Kubernetes集群,使用一段时间之后可能会有重新

  • Centos7 安装部署Kubernetes(k8s)集群实现过程

    目录 一.系统环境 二.前言 三.Kubernetes 3.1 概述 3.2 Kubernetes 组件 3.2.1 控制平面组件 3.2.2 Node组件 四.安装部署Kubernetes集群 4.1 环境介绍 4.2 配置节点的基本环境 4.3 节点安装docker,并进行相关配置 4.4 安装kubelet,kubeadm,kubectl 4.5 kubeadm初始化 4.6 添加worker节点到k8s集群 4.7 部署CNI网络插件calico 4.8 配置kubectl命令tab键自

  • Kubernetes中创建命名空间实现方法

    目录 正文 命名空间类型 查看命名空间 创建命名空间 结论 正文 命名空间系统对计算来说并不陌生,我们大多数人可能在几乎所有编程语言中都见过命名空间,无论您在哪里遇到命名空间,其基本目的都是相同的:用于逻辑分组. 同样,在 Linux 内核中,也有命名空间的概念,比如存储和网络命名空间.每个容器也有自己的存储命名空间和网络命名空间,用于资源的隔离和分配. Kubernetes命名空间是指由同一物理集群支持的虚拟集群,此选项专为在多个用户分布在多个工作团队或项目的环境中使用而设计. 本文将介绍如何

  • Kubernetes k8s configmap 容器技术解析

    目录 1.什么是 ConfigMap? 2.ConfigMap 能带来什么好处? 3.ConfigMap 三种创建方式 4.ConfigMap 作为环境变量三种使用方式 单个引用 多个引用 args 方式传递环境变量 5.挂载 volume 6.Secret 使用 7.应用程序怎么做到不重启情况下读取最新配置 总结 1.什么是 ConfigMap? ConfigMap 是用来存储配置文件的 Kubernetes 资源对象,配置对象存储在 Etcd 中,配置的形式可以是完整的配置文件.key/va

  • Go语言k8s kubernetes使用leader election实现选举

    目录 一.背景 二.官网代码示例 三.锁的实现 一.背景 在kubernetes的世界中,很多组件仅仅需要一个实例在运行,比如controller-manager或第三方的controller,但是为了高可用性,需要组件有多个副本,在发生故障的时候需要自动切换.因此,需要利用leader election的机制多副本部署,单实例运行的模式.应用程序可以使用外部的组件比如ZooKeeper或Etcd等中间件进行leader eleaction, ZooKeeper的实现是采用临时节点的方案,临时节

  • Kubernetes 权限管理认证鉴权详解

    目录 正文 认证 认证用户 Normal Users Service Accounts 认证策略 客户端证书 不记名令牌 Static Token File Service Account Tokens OpenID Connect Tokens 鉴权 鉴权流程 鉴权模块 RBAC Role 和 ClusterRole RoleBinding 和 ClusterRoleBinding Service Account 最后 正文 Kubernetes 主要通过 API Server 对外提供服务,

  • Larave框架通过sanctum进行API鉴权详解

    目录 目标 步骤 安装启动 安装扩展包 修改配置文件 数据库迁移 模拟数据 添加访问路由 测试获取token postman测试 测试其他接口 知识点补充1 知识点补充2 代码仓库 目标 1.使用laravel框架进行用户的登录,注册,认证 2.前后端分离的情况下,用户请求接口,使用API token进行认证 步骤 安装启动 composer create-project laravel/laravel example-appcd example-app   php artisan serve

  • Spring Boot 访问安全之认证和鉴权详解

    目录 拦截器 认证 鉴权 在web应用中有大量场景需要对用户进行安全校,一般人的做法就是硬编码的方式直接埋到到业务代码中,但可曾想过这样做法会导致代码不够简洁(大量重复代码).有个性化时难维护(每个业务逻辑访问控制策略都不相同甚至差异很大).容易发生安全泄露(有些业务可能不需要当前登录信息,但被访问的数据可能是敏感数据由于遗忘而没有受到保护). 为了更安全.更方便的进行访问安全控制,我们可以想到的就是使用springmvc的拦截器(HandlerInterceptor),但其实更推荐使用更为成熟

  • 话说Spring Security权限管理(源码详解)

    最近项目需要用到Spring Security的权限控制,故花了点时间简单的去看了一下其权限控制相关的源码(版本为4.2). AccessDecisionManager spring security是通过AccessDecisionManager进行授权管理的,先来张官方图镇楼. AccessDecisionManager AccessDecisionManager 接口定义了如下方法: //调用AccessDecisionVoter进行投票(关键方法) void decide(Authent

  • 关于Mongodb 认证鉴权你需要知道的一些事

    前言 本文主要给大家介绍了Mongodb认证鉴权的一些相关内容,通过设置认证鉴权会对大家的mongodb安全进一步的保障,下面话不多说了,来一起看看详细的介绍吧. 一.Mongodb 的权限管理 认识权限管理,说明主要概念及关系 与大多数数据库一样,Mongodb同样提供了一套权限管理机制. 为了体验Mongodb 的权限管理,我们找一台已经安装好的Mongodb,可以参照这里搭建一个单节点的Mongodb. 直接打开mongo shell: ./bin/mongo --port=27017 尝

  • Springboot集成Spring Security实现JWT认证的步骤详解

    1 简介 Spring Security作为成熟且强大的安全框架,得到许多大厂的青睐.而作为前后端分离的SSO方案,JWT也在许多项目中应用.本文将介绍如何通过Spring Security实现JWT认证. 用户与服务器交互大概如下: 客户端获取JWT,一般通过POST方法把用户名/密码传给server: 服务端接收到客户端的请求后,会检验用户名/密码是否正确,如果正确则生成JWT并返回:不正确则返回错误: 客户端拿到JWT后,在有效期内都可以通过JWT来访问资源了,一般把JWT放在请求头:一次

  • Django Rest Framework实现身份认证源码详解

    目录 一.Django框架 二.身份认证的两种实现方式: 三.身份认证源码解析流程 一.Django框架 Django确实是一个很强大,用起来很爽的一个框架,在Rest Framework中已经将身份认证全都封装好了,用的时候直接导入authentication.py这个模块就好了.这个模块中5个认证类.但是我们在开发中很少用自带的认证类,而是根据项目实际需要去自己实现认证类.下面是内置的认证类 BaseAuthentication(object):所有的认证相关的类都继承自这个类,我们写的认证

  • Yii2 rbac权限控制之rule教程详解

    在我们之前Yii2搭建后台并实现rbac权限控制完整实例教程中,不知道你曾经疑惑过没有一个问题,rule表是做什么的,为什么在整个过程中我们都没有涉及到这张表? 相信我不说,部分人也都会去尝试,或百度或google,到头来也会竹篮打水,这部分讲解的内容少之又少啊! 对于一般的权限系统而言,我们之前做的rbac一般情况下是足够的,即时没有rule,相信你也能实现我们用rule实现的功能. 我们就以官网的例子给出一个具体的操作教程,看看这个神秘的rule到底是做什么的! 看需求: 我们有管理员和普通

  • 云原生技术kubernetes调度单位pod的使用详解

    k8s中的最小调度单位---pod 之前的文章中,我们对k8s能够解决的问题做了简单介绍,简单来说,它解决的问题是容器的编排与调度,它的核心价值在于:运行在大规模集群的任务之间,实际上存在着各种各样的关系,这些关系的处理,才是任务编排和系统管理最困难的地方,k8s就是为了这个问题而生的. 这句话比较难理解,我们从已有的知识入手,抽丝剥茧,慢慢理解它.我们已经知道,容器的本质是一个进程,它包含三个部分: 如果说容器是云环境的一个进程,那么你可以将k8s理解成云环境中的一个操作系统. 在一个操作系统

  • go goth封装第三方认证库示例详解

    目录 简介 快速使用 更换 store 总结 简介 当前很多网站直接采用第三方认证登录,例如支付宝/微信/ Github 等.goth封装了接入第三方认证的方法,并且内置实现了很多第三方认证的实现: 图中截取的只是goth支持的一部分,完整列表可在其GitHub 首页查看. 快速使用 本文代码使用 Go Modules. 创建目录并初始化: $ mkdir goth && cd goth $ go mod init github.com/darjun/go-daily-lib/goth 安

随机推荐