在过去的一年里，我们一直致力于K8S环境，在这个环境中，每个用户都可以访问所有名称空间。但当我们在集群中引入新的应用程序时，只向用户授予所需的访问权限是很重要的。
我们很少有在命名空间中运行的服务，例如ABC。由于没有限制，用户可以转发服务并访问它。现在有了新的限制，他们无法访问这些服务。
是否有一种方法可以授予用户端口转发访问权限，而不会影响安全性？
您所需要的被称为RBAC。
基于角色的访问控制(RBAC(是一种基于组织内单个用户的角色来管理对计算机或网络资源的访问的方法。
RBAC授权使用RBAC.authorization.k8s.io API组来驱动授权决策，允许您通过Kubernetes API动态配置策略。
RBAC身份验证规则使用K8s资源配置，这些资源可以分为两组：
-
Role和ClusterRole包含表示一组权限的规则，它指定可以对哪些资源执行哪些操作，如果要在命名空间中定义角色，请使用Role；如果要在集群范围内定义角色，则使用ClusterRole。点击此处了解更多信息。 -
RoleBindings和ClusterRoleBindings将上述role和ClusterRole绑定到特定的主题列表(用户、组、服务帐户(。RoleBinding授予特定命名空间内的权限，而ClusterRoleBinding则授予集群范围的访问权限。点击此处了解更多信息。
本教程中有一个kubectl port-forward的示例Role和RoleBinding。
为了进一步举这个例子，假设您只想让一个人访问端口转发。你必须创建一个RBAC角色，让这个人只做这件事：
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: my-namespace
name: allow-port-forward
rules:
- apiGroups: [""]
resources: ["pods", "pods/portforward"]
verbs: ["get", "list", "create"]
这在命名空间my命名空间中设置了一个角色，并允许该角色在pods和pods/portforward上获取、列出和创建。这些是允许某人转发所需的所有权限。此人将能够在此命名空间中列出pod。然后将此角色绑定到用户：
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: allow-port-forward
namespace: my-namespace
subjects:
- kind: User
name: bob
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: allow-port-forward
apiGroup: ""
这将赋予用户bob在命名空间my namespace中执行上述操作的权限
因此，这里的答案是为每个应该能够使用kubectl port-forward的用户添加rbac身份验证规则。