rbac

*本文作者系VMware中国研发中心研发工程师 马陈龙 目标 本文将介绍如何使用kubefate在两个kubernetes集群上部署互通的两个FATE。这两个FATE可以完成各种联邦学习的任务。 完成后将会得到下图的结构： 先决条件 两个独立的kubernetes集群 v1.16.0+； 两个集群都可以连接互联网也可以互通； 两个部署机器，分别可以执行两个集群的kubectl命令； 两个kubernetes都已经部署了ingress-controller ； 本教程的两个kubernetes集群我们分别称为【 A集群 】和【 B集群 】 部署的两个FATE实例分别称为【 PartyA 】和【 PartyB 】 开始 检查集群 A集群 的信息 [deploy-A]$ kubectl get node -o wide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME master Ready master 191d v1 .17.3 192.168.10.1 <none> CentOS Linux 7 (Core) 3.10.0-1062.12.1 .el7.x86_64 docker: //19.3.5 node -0 Ready <none>

前言 　　上个月，我写了两篇微服务的文章：《 .Net微服务实战之技术架构分层篇 》与《 .Net微服务实战之技术选型篇 》，微服务系列原有三篇，当我憋第三篇的内容时候一直没有灵感，因此先打算放一放。 　　本篇文章与源码原本打算实在去年的时候完成并发布的，然而我一直忙于公司项目的微服务的实施，所以该篇文章一拖再拖。如今我花了点时间整理了下代码，并以此篇文章描述整个实现思路，并开放了源码给予需要的人一些参考。 　　源码： https://github.com/SkyChenSky/Sikiro.RBAC RBAC 　　Role-Based Access Contro翻译成中文就是 基于角色的访问控制 ，文章以下我都用他的简称 RBAC 来描述。 　　现信息系统的 权限控制 大多数采取RBAC的思想进行实现，其 本质思想 是对系统各种的操作权限不是直接授予具体的某个用户，而是在用户集合与权限集合之间建立一个角色，作为 间接 关联。每一种角色对应一组相应的权限。一旦用户被分配了适当的角色后，该用户就拥有此角色的所有操作权限。 　　通过以上的描述，我们可以分析出以下信息： 　　用户与权限是通过角色间接关联的 　　角色的本质就是权限组（权限集合） 　　这样做的好处在于，不必在每次创建用户时都进行分配权限的操作，只要分配用户相应的角色即可，而且角色的权限变更比用户的权限变更要少得多

一、用户和角色的关系 一般系统当中，一个用户可能有多种角色，一个角色可能对应着多个用户，在本实例中，我们先考虑吧比较简单的情况，即一个角色对应多个用户，一个用户只有一个角色的情况。 二、创建管理员model，用来操作数据库 model>admin.js下新建管理员的schema，用来操作admin表 module.exports = app => { const mongoose = app.mongoose; const Schema = mongoose.Schema; var d = new Date(); const AdminSchema = new Schema({ username: { type: String }, password: { type: String }, mobile: { type: String }, email: { type: String }, status: { type: Number, default: 1 }, role_id: { type: Schema.Types.ObjectId }, add_time: { type: Number, default: d.getTime() }, is_super: { type: Number } }); return mongoose.model("Admin",

前言 　　上个月，我写了两篇微服务的文章：《 .Net微服务实战之技术架构分层篇 》与《 .Net微服务实战之技术选型篇 》，微服务系列原有三篇，当我憋第三篇的内容时候一直没有灵感，因此先打算放一放。 　　本篇文章与源码原本打算实在去年的时候完成并发布的，然而我一直忙于公司项目的微服务的实施，所以该篇文章一拖再拖。如今我花了点时间整理了下代码，并以此篇文章描述整个实现思路，并开放了源码给予需要的人一些参考。 　　源码： https://github.com/SkyChenSky/Sikiro.RBAC RBAC 　　Role-Based Access Contro翻译成中文就是 基于角色的访问控制 ，文章以下我都用他的简称 RBAC 来描述。 　　现信息系统的 权限控制 大多数采取RBAC的思想进行实现，其 本质思想 是对系统各种的操作权限不是直接授予具体的某个用户，而是在用户集合与权限集合之间建立一个角色，作为 间接 关联。每一种角色对应一组相应的权限。一旦用户被分配了适当的角色后，该用户就拥有此角色的所有操作权限。 　　通过以上的描述，我们可以分析出以下信息： 　　用户与权限是通过角色间接关联的 　　角色的本质就是权限组（权限集合） 　　这样做的好处在于，不必在每次创建用户时都进行分配权限的操作，只要分配用户相应的角色即可，而且角色的权限变更比用户的权限变更要少得多

本文配套教学视频： B站观看地址 在本号之前写过的一些文章中，笔者使用了lambda表达式语法，一些读者反映说代码看不懂。本以为java 13都已经出了，java 8中最重要特性lambda表达式大家应该都掌握了，实际上还是存在大量的程序员没有使用java8，还有的使用了java8也不会使用lambda表达式。 Lambda表达式是Java 8最流行最常用的功能特性。它将函数式编程概念引入Java，函数式编程的好处在于可以帮助我们节省大量的代码，非常方便易用，能够大幅度的提高我们的编码效率。在本文中，我们将介绍lambda表达式是什么，并将传统的java代码写法转换为lambda表达式写法，大家可以通过示例了解lambda表达式都对传统代码做了哪些简化。 本文配套教学视频： B站观看地址 一、接口定义 首先，我们要明白lambda表达式在表达什么？答案就是lambda表达式表达接口函数的实现，所以我们有必要做一下准备工作。在传统的开发方式下，我们不习惯将代码块传递给函数。我们所有的行为定义代码都封装在方法体内，并通过对象引用执行，就像使用下面的代码一样： public class LambdaDemo { //函数定义 public void printSomething(String something) { System.out.println(something); } /

准入控制 kubernetes的安全框架 访问k8s集群需要过三关： 鉴权（Authentication），授权（Authorization），准入控制（Admission Control） 普通用户要安全访问apiServer往往需要证书，token或者用户名 传输安全，认证，授权，准入控制 传输安全 告别8080，迎接6443 全面基于HTTPS通信 鉴权：三种客户端身份认证： HTTPS 证书认证：基于CA证书签名的数字证书认证 HTTP Token认证：通过一个Token来识别用户 HTTP Base认证：用户名+密码的方式认证 授权： RBAC（Role-Based Access Control，基于角色的访问控制）：负责完成授权（Authorization）工作。 根据API请求属性，决定允许还是拒绝。 准入控制： Adminssion Control实际上是一个准入控制器插件列表，发送到API Server的请求都需要经过这个列表中的每个准入控制器插件的检查，检查不通过，则拒绝请求。 RBAC授权 RBAC（Role-Based Access Control，基于角色的访问控制），允许通过Kubernetes API动态配置策略。 角色 Role：授权特定命名空间的访问权限 ClusterRole：授权所有命名空间的访问权限 角色绑定 RoleBinding

Arctic Code Vault Contributor 上榜了，内心比较喜悦，谢谢开源社区的支持，也谢谢广大 coder 的支持； go-admin 是一个基于 Gin + Vue + Element UI 的前后端分离权限管理系统脚手架（包含了：基础用户管理功能，jwt 鉴权，代码生成器，RBAC 资源控制，表单构建等） 演示地址： http://www.zhangwj.com 在线文档 https://wenjianzhang.github.io/go-admin-site 国际仓库 https://github.com/wenjianzhang/go-admin 国内仓库 https://gitee.com/mydearzwj/go-admin 视频教程 https://space.bilibili.com/565616721/channel/detail?cid=125737 新增功能： 新增了开发模式单独控制部分属性： 开发模式中 token 过期时长； login 接口开发模式中不需填写验证码； 菜单一键生成到数据库； api 接口配置一键生成到数据库； 表单构建工具升级： 添加富文本等组件； 修复已知 bug ； 数据库类型增加 sqlite3，postgres 的支持； 更新文档说明； 不断更新的教程 轻松实现 go-admin 写出第一个应用 - 文档教程

k8s集群上的监控首推prometheus，但如果按照x86架构k8s集群安装prometheus的方法直接在树莓派k8s集群上安装prometheus，适配的工作量比较大，不建议这么做。我推荐github上一个大神的作品 https://github.com/carlosedp/cluster-monitoring ， 经反复验证，在树莓派k8s集群基本可用，这里我简单介绍一下安装过程。 安装准备 树莓派k8s集群：最好3节点，单节点也可以。 root@pi4-master01:~# kubectl get nodes -o wide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME pi4-master01 Ready master 4d18h v1.15.10 192.168.5.18 <none> Ubuntu 20.04 LTS 5.4.0-1011-raspi docker://18.9.9 pi4-node01 Ready node 4d17h v1.15.10 192.168.5.19 <none> Ubuntu 20.04 LTS 5.4.0-1011-raspi docker://18.9.9 pi4-node02

缘起 我接触 ES 的时间大约是2017年，最初是小打小闹，只是搭了个小的demo环境，用ES来存储给设备日志外加用Kibana做一些简单的可视化展示，自我娱乐和研究而已， 对于ES本身的知识也只是限于碎片化的学习。 2018~2019年是个逐渐井喷的阶段，那时候公司有几个千亿级日志收集和处理的项目开始上马，我作为项目架构师，自然要对Elastic stack玩得更加精深一点，于是便决心想要体系化的学习一下。正好在2019年7月极客时间推出了阮一鸣的ES7.1的视频课，那时便毫不犹豫的买了下来，2019年9月开始被assign到一个AIOps的项目中去，所以之后也只是断断续续的学习。 但也正是在那个AIOps的项目中，我对ES这个强大的数据平台及其与上下游周边系统的关系有了更加清晰的认识，今年年初老板同我谈起建设运维自动化平台的想法，于是想要拿下Elastic 认证的决心也就坚定了下来。 准备过程 Elastic 认证在业内素来有着难通过的“恶名”，而且因为考的全是实操题，所以如果自己没有动手实践的经验是肯定不能通过考试的。3个小时10个大题，每个题目必须分秒必争，也就意味着必须对ES中的各种概念有着非常深刻的理念，并且知道他们出现在官方文档的什么位置才行。抱着这个认识，我的复习准备之路一共分为3个阶段。 2.1 5月16日 到6月15日 第一阶段 今年5/1考完CKA认证后

Oracle表与用户关联 每一个用户，需要确定表存放位置，这个位置称为表空间 在Oracle中表空间分2中：永久表空间、临时表空间 临时表空间：使用SQL语句操作时，结果先进入临时表空间 永久表空间：当执行commit时，数据将从 临时表空间 到 永久表空间 。 用户权限和RBAC(了解) 赋予用户dba角色 grand dba to 用户名 RBAC(Role-Based Access Control) 基于角色的访问控制 增强权限的可维护性 1、创建用户 语法 -- 创建用户 create user 用户名 identified by 密码 default tablespace 表空间 temproary tablespace 临时表空间 quota 大小 on 表空间; //当前用于指定的表空间的限额大小 实例 -- 创建用户 create user tqyl identified by tqyl default tablespace tqyl temporary tablespace tqyltemp quota 50m on tqyl; --赋予用户所有权限(管理员权限dba) -- grant dba to 用户名; grant dba to tqyl; 2、创建表空间(永久) 基本语法 create tablespace 表空间名称 datafile '表空间保存位置