rbac

工作流是企业信息系统的核心和灵魂，在公司管理和运转中引入审批工作流，替代原本的纸质申请和审批，可以有效提高公司的运转效率以及公司管理制度的规范化。 通常，工作流所包含的页面内容基本上没有大的差别，更多的是在内部逻辑数据的处理上，可以关注一下几点： 一．角色 在企业中，每个人都会有自己的岗位职责和层级之分，不同的岗位和层级定位不一样，需要完成的任务也不一样。 在审批流程中，大致抽象划分为两类： 1.发起人 流程的发起人是一个流程的所有者，也是比较关心审批进展的人，发起人完成的主要是事务性、操作性的工作。从发起人的角度来说，在创建完审批事项后，还需要完善相关信息、催促审批人及时审批、处理驳回修改意见、重新提交等。发起人角度设计的要点是：兼容统一发起入口和业务场景触发常用的审批事项要方便找到有统一汇总的审批管理页面。 2.审批人 审批人在流程中需要完成的主要是决策性的工作，因此在审批人的视角，内容和操作都应该尽量精简： 只看到最重要的信息，避免信息过多影响判断只进行必要操作，不能有过多选择或过多输入，影响决策效率统一的页面进行审批操作和管理需要有审批历史，以便追溯。 二. 内容 提炼最小集合 根据审批事项的不同，流转内容也会有所不同。对于审批流程的设计来说，需要在实际业务中提炼出最核心的内容，一则可以减轻发起人的工作负担（发起一个审批要填一堆的资料相信没人会开心）

如何解决多租户集群的安全隔离问题是企业上云的一个关键问题，本文主要介绍kubernetes多租户集群的基本概念和常见应用形态，以及在企业内部共享集群的业务场景下，基于kubernetes原生和ACK集群现有安全管理能力快速实现多租户集群的相关方案。 什么是多租户集群？ 这里首先介绍一下"租户"，租户的概念不止局限于集群的用户，它可以包含为一组计算，网络，存储等资源组成的工作负载集合。而在多租户集群中，需要在一个集群范围内（未来可能会是多集群）对不同的租户提供尽可能的安全隔离，以最大程度的避免恶意租户对其他租户的攻击，同时需要保证租户之间公平地分配共享集群资源。 在隔离的安全程度上，我们可以将其分为软隔离(Soft Multi-tenancy)和硬隔离（Hard Multi-tenancy）两种。其中软隔离更多的是面向企业内部的多租需求，该形态下默认不存在恶意租户，隔离的目的是为了内部团队间的业务保护和对可能的安全攻击进行防护；而硬隔离面向的更多是对外提供服务的服务供应商，由于该业务形态下无法保证不同租户中业务使用者的安全背景，我们默认认为租户之间以及租户与k8s系统之间是存在互相攻击的可能，因此这里也需要更严格的隔离作为安全保障。关于多租户的不同应用场景，在下节会有更细致的介绍。 多租户应用场景 下面介绍一下典型的两种企业多租户应用场景和不同的隔离需求： 1

目录 文章目录 目录 基于命名空间的多用户模型 基于层级命名空间的多租户隔离 示例 基于命名空间的多用户模型 在单个 Kubernetes Cluster 上安全托管多用户一直是个难题。其中最大的麻烦就是不同的组织会以不同的方式使用 Kubernetes，很难找到一种通用的多用户模型来适配所有组织。但是，Kubernetes 只提供了创建不同多用户模型的基础构件，例如：Namesapce、RBAC、NetworkPolicies。 其中最重要的就是 Namespace，它构成了 Kubernetes 控制平面的安全和共享策略的骨干。Namespace 有两个关键属性，使其成为策略执行的理想选择： 首先，Namespace 可以用于表示所有权。通常的，Kubernetes 大多数的对象资源都会被划分到某个 Namespace 中。所以，如果我们使用 Namespace 来代表资源的所有权的话，那么一个 Namespace 中的所有资源对象都被描述为属于同一个用户。 其次，Namespace 的创建和使用需要进行认证、鉴权、授权。只有超级管理员才能创建 Namesapce，其他用户需要明确的权限才能使用这些 Namespace，包括：创建、查看和修改 Namespace 下属的资源对象。所以，可以通过设置恰当的安全策略，来防止非特权用户操作特定的资源对象。 然而在实际使用中

Openshift首个支持企业级 Java 的 PaaS 平台，支持 JEE6 与 JBoss 和其 Eclipse 集成开发环境以及 Maven 和 Jenkins 自动化。使用 OpenShift 的人数及社区人数在不断增长。OpenShift基于Kubernetes，增加哪儿些功能？有什么区别? Openshift 的 Web console Openshift的web console采用node.js 与angularJS开发，支持实时推送,如下示例 集成容器管理与ImageStream OpenShift Container Registry 自动管理镜像的版本，ImageStream包含所有镜像的原数据，但ImageStream不包含Image数据。 使用Image Stream的目的是方便地将一组相关联的镜像进行整合管理和使用。 Openshift默认为用户定义了一系列开箱即用的Image Stream。 查看Image Stream对象 oc get is -n openshift Native CI/CD factory 原生支持Pipeline的Build实现CI/CD过程 Jenkins Plugin能直接触发openshift的构建和部署过程, 同时最吸引的特点是: 支持流水线Pipeline这种模式,便于在同一集群的多个项目(对应开发，测试，生产

Openshift首个支持企业级 Java 的 PaaS 平台，支持 JEE6 与 JBoss 和其 Eclipse 集成开发环境以及 Maven 和 Jenkins 自动化。使用 OpenShift 的人数及社区人数在不断增长。OpenShift基于Kubernetes，增加哪儿些功能？有什么区别? Openshift 的 Web console Openshift的web console采用node.js 与angularJS开发，支持实时推送,如下示例 集成容器管理与ImageStream OpenShift Container Registry 自动管理镜像的版本，ImageStream包含所有镜像的原数据，但ImageStream不包含Image数据。 使用Image Stream的目的是方便地将一组相关联的镜像进行整合管理和使用。 Openshift默认为用户定义了一系列开箱即用的Image Stream。 查看Image Stream对象 oc get is -n openshift Native CI/CD factory 原生支持Pipeline的Build实现CI/CD过程 Jenkins Plugin能直接触发openshift的构建和部署过程, 同时最吸引的特点是: 支持流水线Pipeline这种模式,便于在同一集群的多个项目(对应开发，测试，生产

本文根据黄东旭在 PingCAP D 轮融资线上发布会的演讲实录进行整理。 TiDB 的现在和未来 大家好，我是黄东旭，是 PingCAP 的联合创始人和 CTO，这是 PingCAP 成立以来的第一次发布会，我想跟大家简单聊聊 TiDB 在产品和技术上的更新。考虑到线上的很多观众不一定是有很强的技术背景，我将尽我所能将技术的部分说得让大家都能够理解。 在讲正题之前有一个小故事，我们做基础软件的产品经理去跟客户聊需求的时候，客户经常都会说：对于数据库，我的要求特别简单、特别基础、非常朴素，我不要求很多功能，安全稳定是必须的，最好能高可用，性能一定要好，如果数据量大了，能实现弹性伸缩就更好了；另外，最好别让我学太多新东西，用起来跟过去使用的产品差不多，这就是一款完美的数据库产品。 就像大家在家里用自来水一样，我们对自来水的需求就是拧开水龙头水就能出来，但是背后自来水厂是怎么处理的大家不用知道，我们只需要根据实际情况使用冷水或者热水就好。但是从技术的角度来说，刚才类似冷热水这个非常朴素的基础需求，类比一下放到数据库的世界这就是一个图灵奖级别的基础需求，稍微解释一下图灵奖是计算机行业学术界最顶级的，相当于计算机界的诺贝尔奖。 这里有两位行业泰斗级的人物，左边 Leslie Lamport 在 2013 年研究相关问题拿了图灵奖，右边这位跟我们挺有缘的，发型跟（我们的 CEO）刘奇同学挺像