IAM是AWS的理论的受权办法。大部分针对AWS的Kubernetes的“疾速入门”指南并没有充沛笼罩如何在你的Pod中治理IAM拜访的相干内容。本系列文章讲探讨Kubernetes环境的AWS IAM特有的安全性问题，而后比照不同计划，并最终具体介绍如何抉择一种计划来设置集群。

在之前的文章中，咱们在生产kubernetes集群中装置了kiam。在本文中，咱们将介绍在成产环境疾速装置kube2iam的过程.

概述

本文将蕴含你在身缠环境部署kube2iamd的以下4步：

  1. 创立 IAM roles
  2. 减少Annotation到Pod
  3. 部署kube2iam
  4. 测试
  5. 全副部署kube2iam

浏览kube2iam详情及个性，请查看 Github Page。

1. 创立IAM Roles

应用kubeiam的第一步是为你的Pod创立IAM roles。kube2iam的工作形式是须要一个IAM策略附加到集群中每个节点以容许其为Pod委派roles。

创立为你的节点一个IAM策略并且附加到你的kubernetes节点的role上。

策略：
{  "Version": "2012-10-17",  "Statement": [    {      "Effect": "Allow",      "Action": [        "sts:AssumeRole"      ],      "Resource": "*"    }  ]}

接下来为每个pod创立role。每个role将须要一个策略，领有Pod性能所需的最小权限，例如：列出S3对象，写入DynamoDB, 读取SQS等。你须要为每个所创立的role更新委派角色策略，以便使你的节点能够委派这些role。用kubernetes节点所附加role的arn替换YOUR_NODE_ROLE。

委派角色策略：
{  "Version": "2012-10-17",  "Statement": [    {      "Action": "sts:AssumeRole",      "Principal": {        "Service": "ec2.amazonaws.com"      },      "Effect": "Allow",      "Sid": ""    },    {      "Sid": "",      "Effect": "Allow",      "Principal": {        "AWS": "YOUR_NODE_ROLE"      },      "Action": "sts:AssumeRole"    }  ]}

2. 为pod减少Annotations

下一步将你的pod将用的role正文到Pod。减少一个annotation到pod 的metadata.spec即可，kube2iam应用IAM对Pod进行身份认证时将应用这个role。如此配置后，kube2iam将为该role主动查看根底arn，然而如果你须要委派角色给其余AWS账号也能够指定一个残缺的arn（以arn:aws:iam开始）。kube2iam文档有一些不同pod控制器的例子。

annotations:   iam.amazonaws.com/role: MY_ROLE_NAME

3. 部署kubeiam

当初能够部署kube2iam。你能够参考kube2iam github repo 获取EKS和OpenShift的例子，然而这里也也会介绍一些通用deployment办法。第一步时配置RBAC：

---apiVersion: v1kind: ServiceAccountmetadata:  name: kube2iam  namespace: kube-system---apiVersion: v1items:  - apiVersion: rbac.authorization.k8s.io/v1    kind: ClusterRole    metadata:      name: kube2iam    rules:      - apiGroups: [""]        resources: ["namespaces","pods"]        verbs: ["get","watch","list"]  - apiVersion: rbac.authorization.k8s.io/v1    kind: ClusterRoleBinding    metadata:      name: kube2iam    subjects:    - kind: ServiceAccount      name: kube2iam      namespace: kube-system    roleRef:      kind: ClusterRole      name: kube2iam      apiGroup: rbac.authorization.k8s.iokind: List

因为kube2iam批改了kubernetes节点上的iptables规定来劫持到EC2 metadata服务的流量，我倡议减少一个tainted的新节点到集群，这样你能够在确保不影响你生产环境Pod的前提下测试控制器来配置正确。为集群减少一个节点而后为其打上五点钟，这样其余Pod就不会被调度到该节点。

export ALICLOUD_ACCOUNT=""export ALICLOUD_ACCESS_KEY="your-access-key"export ALICLOUD_SECRET_KEY="your-secret-key"export ALICLOUD_REGION="cn-qingdao"
kubectl taint nodes NODE_NAME kube2iam=kube2iam:NoSchedule

接下来咱们能够在该节点上配置agent。减少nodeName: NEW_NODE_NAME到Pod.spec，而后减少tolerations这样它就能够被调度到该节点。设置镜像版本为标记过的公布版本而非latest。还须要设置--host-interface命令参数来适配你的CNI。kube2iam页面有残缺的反对列表。我也倡议设置 --auto-discover-base-arn 和 --auto-discover-default-role 参数来时配置和迁徙更容易。如果你的集群再单个可用区--use-regional-sts-endpoint会很有用，然而你必须为其设置 AWS_REGION 环境变量。综上所述，配置大抵如下：

apiVersion: apps/v1kind: DaemonSetmetadata:  name: kube2iam  namespace: kube-system  labels:    app: kube2iamspec:  selector:    matchLabels:      name: kube2iam  template:    metadata:      labels:        name: kube2iam    spec:      nodeName: NEW_NODE_NAME      tolerations:       - key: kube2iam         value: kube2iam         effect: NoSchedule      serviceAccountName: kube2iam      hostNetwork: true      containers:        - image: jtblin/kube2iam:0.10.6          imagePullPolicy: Always          name: kube2iam          args:            - "--app-port=8181"            - "--auto-discover-base-arn"            - "--iptables=true"            - "--host-ip=$(HOST_IP)"            - "--host-interface=weave"            - "--use-regional-sts-endpoint"            - "--auto-discover-default-role"            - "--log-level=info"          env:            - name: HOST_IP              valueFrom:                fieldRef:                  fieldPath: status.podIP            - name: AWS_REGION              value: "us-east-1"          ports:            - containerPort: 8181              hostPort: 8181              name: http          securityContext:            privileged: true

接下来你能够创立agent并确认该agent运行于你的新节点上。你其余节点上的Pod不会有变更。

4. 测试

在这一步，开始测试以冀望一切正常。你能够通过在该隔离节点部署一个Pod，而后在该POD中应用AWS CLI拜访资源进行测试。当你做这些时，请查看kube2iam agent的日志来debug你遇到的的问题。这里有个deployment实例，你能够指定一个role而后用它进行拜访测试。

apiVersion: apps/v1beta2kind: Deploymentmetadata:  name: aws-iam-tester  labels:    app: aws-iam-testerspec:  replicas: 1  strategy:    type: Recreate  selector:    matchLabels:      app: aws-iam-tester  template:    metadata:      labels:        app: aws-iam-tester      annotations:        iam.amazonaws.com/role: TEST_ROLE_NAME    spec:      nodeSelector:        kubernetes.io/role: node      nodeName: NEW_NODE_NAME      tolerations:       - key: kube2iam         value: kube2iam         effect: NoSchedule      containers:      - name: aws-iam-tester        image: garland/aws-cli-docker:latest        imagePullPolicy: Always        command:          - /bin/sleep        args:          - "3600"        env:          - name: AWS_DEFAULT_REGION            value: us-east-1

Pod将会在一个小时后退出，你能够应用kubectl获取一个TTY到Pod。

kubectl exec -ti POD_NAME /bin/sh

一旦你确认你的role能够失常工作，并且kube2iam agent配置失常，你就能够部署agent到每个节点。

5. 全量部署kube2iam

从kube2iam Daemonset删除nodeName和kub2iam:kub2iam以容许它运行到每个节点。 在每个节点装置实现当前，应该对要害pod进行更新，以这些Pod立刻应用kube2iam进行验证。其余已经应用node role进行认证的的Pod当其长期凭据过期后将开始应用kube2iam进行认证（通常是一个小时）。若IAM认证有错，请查看你的利用及kubeiam日志。

当所有运行失常，你就能够删除再次之前增加的隔离节点。

遇到问题时，你能够删除所有节点上的agent，然而它不会主动清理它创立的iptable规定。这将导致所有发往EC2 metada的申请不起作用。你须要别离登录到每个节点并手动移除这些iptables规定。

首先列出iptable规定，找出kube2iam所创立的局部

sudo iptables -t nat -S PREROUTING | grep 169.254.169.254

输入大略如下：

-A PREROUTING -d 169.254.169.254/32 -i weave -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.0.101.101:8181

如果你意外的应用不同的--host-interface选项部署agent你可能会看到多个后果。你能够一次删除他们。删除一条规定应用iptables的-D选项并指定-A选项输入的具体行号，例如：

sudo iptables -t nat -D PREROUTING -d 169.254.169.254/32 -i weave -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.0.101.101:8181

当每个节点上都执行过后，EC2 metadta申请将不在发往kube2iam.

论断

当初有kube2iam运行于你的生产集群以及，并为POD创立独立的角色。
如果你的对其余阿计划看趣味，请查看我之前写的[kiam装置]()一文。它更加简单，并且应用不同的办法解决IAM的问题。我也在关注 kube-aws-iam-controller作为代替计划，然而该我的项目始终不太成熟不适宜生产环境。你可也能够查看本系列第一，第二篇文章来理解kubernetes中应用AWS IAM的问题，以及对kiam和kube2iam作为解决方案的深刻比拟。

因在下英文太烂，如果能够您浏览英文，强烈建议 查看原文

FAQ & Checklist

Question: Add support for Instance Metadata Service Version 2 (IMDSv2)

Question: 留神你的集群所应用的网络计划，比方：文中例子为weave，我的集群为Calico，所以应该批改为cali+。否则会报如下谬误：

$ k logs kube2iam-ltm7f -n kube-system...time="2020-07-17T10:47:30Z" level=fatal msg="route ip+net: no such network interface"
Question 2: 默认状况下kube2iam应用8181端口，因为我的worker node应用了8181端口，须要减少2个参数 --app-port=8182 --metrics-port=8183，否则会报如下谬误：
$ k logs kube2iam-bk59z -n kube-systemtime="2020-07-18T03:42:04Z" level=info msg="Listening on port 8181"time="2020-07-18T03:42:04Z" level=fatal msg="Error creating kube2iam http server: listen tcp :8181: bind: address already in use"
Question 3: 应用文中命令未找到相应的iptables规定
$ sudo iptables -t nat -S PREFOUTING | grep 169.254.169.254iptables: No chain/target/match by that name.# 尝试如下命令sudo iptables -t nat -L | grep 169.254.169.254