iam role使用场景_使用IAM和RBAC保护Amazon EKS集群

iam role使用场景

You may have heard people refer to Kubernetes as API centric. That is, what happens in the cluster revolves around a core component in the control plane (or master node) known as the API Server. The API server is like a gatekeeper for your entire cluster. If you want to CRUD (Create, Read, Update, Delete) any Kubernetes objects, it has to go through this API. The API Server validates and configures the API objects such as pods, services, replication controllers and deployments. All of the interaction that takes place between the different clients and the API Server are REST based in order to fulfil the various CRUD operations. The clients interacting with the API Server range from the engineers using the kubectl CLI to nodes which have the kubelet (a node agent) running. Furthermore, the rest of the control plane, that is the scheduler and the controllers, are always talking to it (the API Server) as well.

您可能已经听说过人们将Kubernetes称为以API为中心。 也就是说,集群中发生的事情围绕控制平面(或主节点)中称为API服务器的核心组件进行。 API服务器就像整个集群的网守。 如果要CRUD(创建,读取,更新,删除)任何Kubernetes对象,则必须通过此API。 API服务器验证并配置API对象,例如Pod,服务,复制控制器和部署。 不同客户端和API服务器之间发生的所有交互都是基于REST的,以便完成各种CRUD操作。 与API Server进行交互的客户端包括使用kubectl CLI的工程师 到运行kubelet(节点代理)的节点。 此外,控制平面的其余部分(即调度程序和控制器)也始终与之通信(API服务器)。

With such an important component that is central to the behaviour and state of the cluster, any incoming requests that are receives need to be validated to prove the authenticity of the requester, as well as checked to ensure that the requester is actually allowed to perform the operations included in the request.

使用如此重要的组件(对于群集的行为和状态至关重要),需要验证接收到的所有传入请求以证明请求者的真实性,并进行检查以确保实际上允许请求者执行请求。请求中包含的操作。

了解API服务器周围的身份验证和授权 (Understanding Authentication & Authorization around the API Server)

认证方式 (Authentication)

Authentication is essentially about proving that you are who you say you are. Kubernetes does not have an internal system for storing and managing user accounts. Users are created and managed outside of the cluster. So how does the authentication flow work? Incoming client requests have credentials embedded or attached to them which then get passed off to an external authentication module or system which validates the user. Amazon EKS uses aws-iam-authenticator for the authentication layer which is a tool that uses IAM credentials to authenticate to the cluster.

身份验证本质上是关于证明自己就是您所说的身份。 Kubernetes没有用于存储和管理用户帐户的内部系统。 在群集之外创建和管理用户。 那么身份验证流程如何工作? 传入的客户端请求具有嵌入或附加到它们的凭据,然后将这些凭据传递到验证用户的外部身份验证模块或系统。 Amazon EKS将aws-iam-authenticator用于身份验证层,该层是使用IAM凭据对集群进行身份验证的工具。

On the other hand, system components such as kubelets, pods, and other components of the control plane also need to authenticate with the API Server. Every pod and every member of the control plane that interacts with the API server gets associated with a Service Account. A Service Account is the identity that they use when authenticating with the API Server.

另一方面,系统组件(例如kubelet,pod和控制平面的其他组件)也需要通过API服务器进行身份验证。 与API服务器交互的每个pod和控制平面的每个成员都与一个服务帐户相关联。 服务帐户是他们在通过API服务器进行身份验证时使用的身份。

授权书 (Authorization)

Authorization is the step that follows the successful validation of a user and it deals with what that user is allowed to do in relation to the different resources on the cluster. Role-based access control (RBAC) is the method of regulating user access.

授权是成功验证用户之后的步骤,它涉及允许用户针对集群上的不同资源执行的操作。 基于角色的访问控制(RBAC)是调节用户访问的方法。

Who can perform which actions on which resources?

可以对哪些资源执行哪些操作

If you want a user to be able to carry out various actions or operations on the cluster, you will have to create some allow rules. When you create a new Kubernetes cluster, your cluster creator (user or role) is given all the keys to the kingdom with admin privilege, even though RBAC denies everything by default.

如果希望用户能够在群集上执行各种操作或操作,则必须创建一些允许规则。 当您创建一个新的Kubernetes集群时,即使RBAC默认拒绝所有内容,您的集群创建者(用户或角色)也将获得具有管理权限的所有王国密钥。

使用RBAC保护API服务器操作 (Securing API Server operations with RBAC)

RBAC authorization uses the rbac.authorization.k8s.io API group and consists of four API objects: Role, ClusterRole, RoleBinding and ClusterRoleBinding.

RBAC授权使用rbac.authorization.k8s.io API组,并且由四个API对象组成:Role,ClusterRole,RoleBinding和ClusterRoleBinding。

  • Role — Used to determine which operations can be carried out on which resources in a specific namespace.

    角色-用于确定可以对特定名称空间中的哪些资源执行哪些操作。
  • ClusterRole — Used to determine which operations can be carried out on which resources in the scope of the entire cluster.

    ClusterRole —用于确定可以在整个集群范围内的哪些资源上执行哪些操作。
  • RoleBinding — Used to determine which users or service accounts are authorized to carry out operations on resources in a given namespace as specified in a Role.

    RoleBinding —用于确定授权哪些用户或服务帐户对角色中指定的给定名称空间中的资源执行操作。
  • ClusterRoleBinding — Used to determine which users or service accounts are authorized to carry out operations on resources across the scope of the cluster as specified in a ClusterRole.

    ClusterRoleBinding —用于确定授权哪些用户或服务帐户对在ClusterRole中指定的跨集群范围的资源执行操作。

将IAM用户和角色映射到EKS集群 (Map IAM Users & Roles to the EKS Cluster)

To map IAM users and roles to k8s users in the EKS cluster, you have to define them in the aws-auth ConfigMap which should exist when after creation of your cluster. To view the existing aws-auth ConfigMap in your cluster, run the following command:

要将IAM用户和角色映射到EKS集群中的k8s用户,您必须在创建集群后应该存在的aws-auth ConfigMap中定义它们。 要查看集群中现有的aws-auth ConfigMap,请运行以下命令:

kubectl describe configmap -n kube-system aws-auth

This should produce the following response:

这将产生以下响应:

apiVersion: v1
kind: ConfigMap
metadata:
name: aws-auth
namespace: kube-system
data:
mapRoles: |
- rolearn: <ARN of instance role (not instance profile)>
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes

To add an IAM user or role to the cluster, you would modify this ConfigMap by adding the respective ARN and a Kubernetes username value to the mapRole or mapUser property as an array item. Below is an example with an additional IAM role and user added to the cluster.

要将IAM用户或角色添加到群集,您可以通过将相应的ARN和Kubernetes用户名值添加到mapRolemapUser属性作为数组项来修改此ConfigMap。 下面是一个示例,该示例具有其他IAM角色和添加到群集的用户。

apiVersion: v1
kind: ConfigMap
metadata:
name: aws-auth
namespace: kube-system
data:
mapRoles: |
- rolearn: arn:aws:iam::<account-id>:role/<cluster-name>
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
- rolearn: arn:aws:iam::<account-id>:role/ops-role
username: ops-role
mapUsers: |
- userarn: arn:aws:iam::<account-id>:user/lukas-rbac-user
username: lukas-rbac-user

创建用于授权的RBAC对象 (Creating RBAC Objects for Authorization)

We’ve already covered the theory of RBAC objects, so we’re going to create a Role and a RoleBinding for the users in our EKS cluster.

我们已经介绍了RBAC对象的理论,因此我们将为EKS集群中的用户创建一个Role和RoleBinding。

In the file below, I create two Roles that permit any users attached to them to perform the following actions in the default namespace.

在下面的文件中,我创建了两个角色,这些角色允许连接到他们的任何用户在默认名称空间中执行以下操作。

  • The ops-actions Role — Any users attached to this Role can perform all actions as specified by the wildcard (*) in the verbs property. Furthermore, they can make all HTTP verb requests to the resources in the specified apiGroups, namely the core API group and the apps API group.

    ops-actions角色-附加到此角色的所有用户都可以执行verbs属性中通配符(*)指定的所有操作。 此外,他们可以对指定apiGroups中资源 (即核心API组和apps API组)进行所有HTTP谓词请求。

  • The engineer-actions Role — Any users attached to this Role can perform read actions (get and list) as specified in the verbs property. Furthermore, they can make these HTTP GET requests to all the pod and services resources of the core API Group.

    工程师动作角色-附加到此角色的所有用户都可以执行动词属性中指定的读取动作(获取和列出)。 此外,他们可以向核心API组的所有pod和服务资源发出这些HTTP GET请求。

---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: ops-actions
namespace: default
rules:
- apiGroups: ["", "apps"] # "" indicates the core API group
resources: ["*"]
verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: engineer-actions
namespace: default
rules:
- apiGroups: [""] # "" indicates the core API group
resources: ["pods","services"]
verbs: ["get","list"]

The next step is to create the respective RoleBindings for the Roles defined above. In the code below, we list the users in the subjects property of the RoleBinding object and attach the RoleBinding to the relevant Role.

下一步是为上面定义的角色创建相应的RoleBindings。 在下面的代码中,我们在RoleBinding对象的subject属性中列出用户,并将RoleBinding附加到相关的Role。

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: ops-performer
namespace: default
subjects:
- kind: User
name: ops-role
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: ops-actions
apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: engineer-performer
namespace: default
subjects:
- kind: User
name: lukas-rbac-user
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: engineer-actions
apiGroup: rbac.authorization.k8s.io

You can add these code snippets to a single file or multiple files depending on your preference. Once you have done so, you can apply these changes to your Kubernetes cluster with the following command:

您可以根据自己的喜好将这些代码片段添加到单个文件或多个文件中。 完成后,可以使用以下命令将这些更改应用于Kubernetes集群:

kubectl create -f <file-name>.yaml

After applying these changes, ensure that they have been created by running the following commands:

应用这些更改之后,请通过运行以下命令确保已创建它们:

kubectl get roles # gets roles created for the default namespace
kubectl get rolebindings # gets rolebindings for the default namespace

使用IAM配置文件测试角色和RoleBindings (Testing Roles & RoleBindings with IAM Profiles)

Assuming you saved the credentials for the IAM user profile and role that you created (in this example ops-role and lukas-rbac-user), you can update your AWS CLI config and credentials files accordingly. If you’ve configured a default profile with your AWS CLI then these files can be found in the following location:

假设您保存了创建的IAM用户配置文件和角色的凭证(在本示例中为ops-role和lukas-rbac-user),则可以相应地更新AWS CLI配置和凭证文件。 如果您已使用AWS CLI配置了默认配置文件,则可以在以下位置找到这些文件:

cd ~/.aws/

Update your credentials file with the IAM user profile access key and secret key.

使用IAM用户配置文件访问密钥和秘密密钥更新您的凭据文件。

# /.aws/credentials[lukas-rbac-user]
aws_access_key_id=<access-key-id>
aws_secret_access_key=<secret-key>

Update your config file with the IAM user profile and the IAM role that will be used to connect to cluster.

使用IAM用户配置文件和将用于连接到群集的IAM角色更新配置文件。

# /.aws/config[profile lukas-rbac-user]
region = eu-west-1[profile ops-role]
role_arn = arn:aws:iam::<account-id>:role/ops-role
source_profile = luke-rbac-user # can use another source profile

After completing the configuration of the profiles with you AWS CLI, you can test the accessibility and operations of each profile with the EKS cluster. Remember to update the AWS_DEFAULT_PROFILE environment variable when switching between profiles. Connect to the cluster with the command below and fire away!

使用AWS CLI完成配置文件的配置后,您可以使用EKS集群测试每个配置文件的可访问性和操作。 在配置文件之间切换时,请记住要更新AWS_DEFAULT_PROFILE环境变量。 使用以下命令连接到集群,然后启动!

aws eks update-kubeconfig --name <eks-cluster-name>

I hope the above proves useful to you as you try to achieve optimal security for the API Server in your EKS cluster. As always, happy coding 😃 💻. If you enjoyed the post, feel free to buy me a coffee here.

希望以上内容对您有所帮助,当您尝试为EKS群集中的API服务器实现最佳安全性时。 和往常一样,快乐编码coding。 如果您喜欢这个职位,请随时在这里给我买咖啡。

翻译自: https://medium.com/swlh/secure-an-amazon-eks-cluster-with-iam-rbac-b78be0cd95c9

iam role使用场景

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值