EN_AWS

1. AWS Assume Role

AWS Assume Role is a way to obtain temporary security credentials (access keys, secret access keys, and session tokens) to access AWS resources in another account or with different permissions within the same account.

• The sts:AssumeRole action allows you to assume a role that exists in another AWS account or within your own account. When you assume a role, you temporarily gain the permissions associated with that role.
• Cross-account access: You can assume a role in another AWS account to access resources in that account.
• Within the same account: Assume a role with different permissions than the user or service executing the current command.

Example of using Assume Role

• The following is how to use Assume Role to grant account A access to account B's EKS resources.

Create IAM Role in Account B

• Create an IAM role in Account B with a trust policy that allows Account A to assume this role. This role grants permission to manage EKS resources in Account B.

Example of creating the AssumeRole role in Account B:

{
  "Version": "2012-10-17",å
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"  // Account A ID
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

• Attach EKS permissions to the role in Account B. Attach required EKS policies, such as AmazonEKSClusterPolicy or custom permissions, to the role to manage EKS resources.

Create an IAM policy in Account A

• In Account A, create an IAM policy that allows users or services in Account A to assume roles in Account B.

Example Account A policy:

코드 복사
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::111122223333:role/EKSAdminRole"  // Role ARN in Account B
    }
  ]
}

• Attach this policy to the required user, group, or role in Account A.

Assuming the role in Account A

• A user or service that has the Assume Role policy in Account A can now assume the role in Account B using the AWS CLI, SDK, or AWS Console.

AWS CLI example:

aws sts assume-role \
  --role-arn arn:aws:iam::111122223333:role/EKSAdminRole \
  --role-session-name eks-session

• This command provides temporary credentials (access key, secret key, and session token) that Account A can use to access and manage EKS resources in Account B.

Using temporary credentials for access

• After assuming the role, you can use your temporary credentials to interact with EKS resources in Account B with the permissions of Account A.

Example of updating kubeconfig to manage an EKS cluster in Account B:

aws eks --region us-west-2 update-kubeconfig --name eks-cluster \
  --role-arn arn:aws:iam::111122223333:role/EKSAdminRole

• You can now use kubectl from Account A to manage the EKS cluster in Account B.

---

2. AWS Ingress Group

• In AWS, ingress group is a function that allows you to manage multiple ingress resources by consolidating them into one load balancer (ALB).
• This allows multiple Kubernetes namespaces or applications from different teams to share the same ALB and set different Ingress rules.
• Using an ingress group can save network resources and increase management efficiency.
• Basically, ingress does not belong to an ingress group, and ingress is an "implicit IngressGroup", that is, it exists as an independent entity.

Ingress Setting the group name

• Define the group name using the alb.ingress.kubernetes.io/group.name annotation.
• Ingress resources with the same group name share one ALB.
• Ingress resources assigned to the ingress group ALB search for the AWS tag ingress.k8s.aws/stack (it is a tag in the listener rule). The value of this tag is the name of the IngressGroup.
• Resources that do not use the ingress group set the tag value in the format namespace/ingressname.
• If you change the groupName assigned to the ingress resource, Ingress will be moved from the existing group to the new IngressGroup and managed in the ALB of the new IngressGroup.
• If the ALB for the new IngressGroup does not exist, a new ALB is automatically created.
• The ALB of the ingress group can be found by searching the AWS tag ingress.k8s.aws/stack with the name of the ingress group as the value.
• Example: alb.ingress.kubernetes.io/group.name: my-team.awesome-group

Setting Ingress Group ranking

• You can specify the order using the alb.ingress.kubernetes.io/group.order annotation.
• Ingress rules with lower numeric order values are applied first, and specific priorities can be specified for the same path or host.
• Example: alb.ingress.kubernetes.io/group.order: 10

Ingress Group Example

In the example below, two ingress resources share a group called my-shared-group and requests are processed by one ALB.

# Ingress for Service A
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: service-a-ingress
  annotations:
    alb.ingress.kubernetes.io/group.name: "my-shared-group"
    alb.ingress.kubernetes.io/group.order: "10"
spec:
  rules:
    - host: "service-a.example.com"
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: service-a
                port:
                  number: 80

# Ingress for Service B
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: service-b-ingress
  annotations:
    alb.ingress.kubernetes.io/group.name: "my-shared-group"
    alb.ingress.kubernetes.io/group.order: "20"
spec:
  rules:
    - host: "service-b.example.com"
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: service-b
                port:
                  number: 80

• service-a and service-b will each belong to the ingress group my-shared-group, and service-a will be applied first as order 10.