rbac | 易学教程

How to execute command from one pod inside another pod using kubectl exec which are inside a same k8s cluster

阅读更多关于 How to execute command from one pod inside another pod using kubectl exec which are inside a same k8s cluster

问题 I have two pods in a cluster. Lets call them A and B. I've installed kubectl inside pod A and I am trying to run a command inside pod B from pod A using kubectl exec -it podB -- bash . I am getting the following error Error from server (Forbidden): pods "B" is forbidden: User "system:serviceaccount:default:default" cannot create pods/exec in the namespace "default" I've created the following Role and RoleBinding to get access. Role yaml kind: Role apiVersion: rbac.authorization.k8s.io/v1

如何管理越来越多的Operator？OLM给你答案

阅读更多关于如何管理越来越多的Operator？OLM给你答案

作者 | 匡大虎、阚俊宝导读： OLM(Operator Lifecycle Manager) 作为 Operator Framework 的一部分，可以帮助用户进行 Operator 的自动安装，升级及其生命周期的管理。同时 OLM 自身也是以 Operator 的形式进行安装部署，可以说它的工作方式是以 Operators 来管理 Operators，而它面向 Operator 提供了声明式 (declarative) 的自动化管理能力也完全符合 Kubernetes 交互的设计理念。本文我们将来了解一下 OLM 的基本架构和安装使用。 OLM 组件模型定义 OLM 的出现是为了帮助没有如大数据，云监控等领域知识的用户能够自助式地部署并管理像 etcd、大数据分析或监控服务等复杂的分布式应用。因此从它的设计目标来说，OLM 官方希望实现面向云原生应用提供以下几个方向上的通用管理能力，包括：生命周期管理：管理 operator 自身以及监控资源模型的升级和生命周期；服务发现：发现在集群中存在哪些 operator，这些 operators 管理了哪些资源模型以及又有哪些 operators 是可以被安装在集群中的；打包能力：提供一种标准模式用于 operator 以及依赖组件的分发，安装和升级；交互能力：在完成了上述能力的标准化后，还需要提供一种规范化的方式（如 CLI

保护Kafka环境的最佳实践

阅读更多关于保护Kafka环境的最佳实践

对于许多企业来说，Kafka是整个企业数据系统的中枢，因此保护事件流平台对于数据安全至关重要，并且通常是管理层要求的。本文会讲述五个安全类别以及Kafka和Confluent平台的基本功能，这些功能可以帮助用户保护事件流平台。认证方式认证机制会验证接入Kafka和Confluent平台的用户和应用的身份。需要关注的与认证相关的主要领域有三个：Kafka的Broker或Confluent的服务端，Apache ZooKeeper的服务端以及基于HTTP的服务。HTTP服务包括Kafka Connect工作节点、ksqlDB服务端、Confluent REST代理、模式注册表和Control Center。验证与这些服务的所有连接是安全的基础。 Kafka Broker和Confluent服务端 Kafka Broker和Confluent服务端使用简单认证和安全层（SASL）或 mutual TLS （mTLS）对来自客户端和其他Broker的连接进行身份验证。 SASL是用于身份验证的框架，提供了多种身份验证机制。当前支持的SASL机制包括 PLAIN 、 SCRAM 、 GSSAPI （Kerberos）和 OAUTHBEARER （注意：OAUTHBEARER的开发者必须提供代码以获取和验证凭据）。Kafka Broker可以同时启用多种机制

Kubernetes RBAC rules for PersistentVolume

阅读更多关于 Kubernetes RBAC rules for PersistentVolume

问题 I'm trying to create RBAC Role / rules for a service that needs a persistent volume and it's still failing with forbidden error. Here is my role config: kind: Role apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: logdrop-user-full-access namespace: logdrop rules: - apiGroups: ["", "extensions", "apps", "autoscaling"] resources: ["*"] verbs: ["*"] - apiGroups: ["batch"] resources: - jobs - cronjobs verbs: ["*"] And this is my cut down PersistentVolume manifest: apiVersion: v1 kind

Kubernetes RBAC rules for PersistentVolume

阅读更多关于 Kubernetes RBAC rules for PersistentVolume

Automatically create Kubernetes resources after namespace creation

阅读更多关于 Automatically create Kubernetes resources after namespace creation

问题 I have 2 teams: devs: they create a new Kubernetes namespace each time they deploy a branch/tag of their app ops: they manage access control to the cluster with (cluster)roles and (cluster)rolebindings The problem is that 'devs' cannot kubectl their namespaces until 'ops' have created RBAC resources. And 'devs' cannot create RBAC resources themselves as they don't have the list of subjects to put in the rolebinding resource (sharing the list is not an option). I have read the official

腾讯工程师经验：如何写一手好代码？

阅读更多关于腾讯工程师经验：如何写一手好代码？

导读：如何写一手好代码，本文值得大伙一读哦。前言作为公司代码委员会 golang 分会的理事，我 Review 了很多代码，看了很多别人的 review 评论。发现不少同学 code review 与写出好代码的水平有待提高。在这里，想分享一下我的一些理念和思路。为什么技术人员包括 leader 都要做 Code Review 谚语曰: 'Talk Is Cheap, Show Me The Code'。知易行难，知行合一难。嘴里要讲出来总是轻松，把别人讲过的话记住，组织一下语言，再讲出来，很容易。绝知此事要躬行。设计理念你可能道听途说了一些，以为自己掌握了，但是你会做么？有能力去思考、改进自己当前的实践方式和实践中的代码细节么？不客气地说，很多人仅仅是知道并且认同了某个设计理念，进而产生了一种虚假的安心感---自己的技术并不差。但是，他根本没有去实践这些设计理念，甚至根本实践不了这些设计理念，从结果来说，他懂不懂这些道理/理念，有什么差别？变成了自欺欺人。代码，是设计理念落地的地方，是技术的呈现和根本。同学们可以在 review 过程中做到落地沟通，不再是空对空的讨论，可以在实际问题中产生思考的碰撞，互相学习，大家都掌握团队里积累出来最好的实践方式！当然，如果 leader 没时间写代码，仅仅是 review 代码，指出其他同学某些实践方式不好，要给出好的实践的意见

kubernetes用户权限管理工具permission-manager

阅读更多关于 kubernetes用户权限管理工具permission-manager

Permission Manager Permission Manager是一个为Kubernetes RBAC和用户管理提供Web UI的项目，为Kubernetes权限管理提供友好的可视化界面。安装从 https://github.com/sighupio/permission-manager/tree/master/deployments/kubernetes 把yaml文件下载下来,如下 [root@qd01-stop-k8s-master001 kubernetes]# ll total 4 -rw-r--r-- 1 root root 2697 Jan 28 11:08 deploy.yml drwxr-xr-x 2 root root 37 Jan 28 11:14 seeds 创建namespace [root@qd01-stop-k8s-master001 kubernetes]# kubectl create namespace permission-manager namespace/permission-manager created 创建秘密并进行相应更新 [rancher@qd01-stop-k8snode011 permission-manager]$ cat secret.yaml --- apiVersion: v1 kind: Secret

Kubernetes - RBAC issue with ingress controller

阅读更多关于 Kubernetes - RBAC issue with ingress controller

问题 I'm following a tutorial by Diego Martínez, outlining how to use an ingress controller with SSL on K8s. Everything works fine, with the exception of an RBAC error: It seems the cluster it is running with Authorization enabled (like RBAC) and there is no permissions for the ingress controller. Please check the configuration Does anyone know how I can grant RBAC permissions to this resource? I'm running on Google Cloud, and for reference, below is the ingress deployment spec 回答1: If you are

k8s rbac 权限管理控制创建过程+理论知识

阅读更多关于 k8s rbac 权限管理控制创建过程+理论知识

前言现在RBAC主要解决的一个问题，就是：所有人都拿的是admin的config文件，因此所有人都拥有最高权限，他可以为所欲为，从而很有可能在不知情的情况下，破坏k8s集群。因此我们需要对其进行控制，给他创建admin之外的账号，让他无法操作k8s系统重要部分的namespace。先不说原理，直接说操作步骤一、创建证书创建user私钥 [root@node-01 ~]cd /etc/kubernetes/pki/ [root@node-01 pki](umask 077;openssl genrsa -out aideveloper.key 2048) Generating RSA private key, 2048 bit long modulus .................................................................................+++ ..................+++ e is 65537 (0x10001) 创建证书签署请求 O=组织信息，CN=用户名 [root@node-01 pki]openssl req -new -key aideveloper.key -out aideveloper.csr -subj "/O=jbt/CN=aideveloper" 签署证书

订阅 rbac