EN_AWS

1. 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. 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.

Reference

• Ingress annotations

---

3. Ingress Traffic Listening

listen-ports- Specifies the ports on which the ALB listens.

• Example: alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}, {"HTTP": 8080}, {"HTTPS": 8443}]'- Applies to all Ingresses within an IngressGroup, so each Ingress can define its own port, and the rule only applies to the ports specified for each Ingress.
• If the same listening port is defined by multiple Ingresses within an IngressGroup, it is applied according to the order of the IngressGroup.
• Default: If listen-ports is not specified and no certificate is used, the default is {"HTTP": 80} and, if a certificate is provided, {"HTTPS": 443}.
• WARNING: You cannot have duplicate load balancer ports within the same group. (Exception: Specifying alb.ingress.kubernetes.io/group.order: 10)
• Defining listen-ports on one Ingress within an IngressGroup is sufficient, as the ALB consolidates these settings for all Ingresses in the group.

ssl-redirect- Enables SSL redirect by specifying the port to which HTTP traffic is redirected (usually HTTPS port 443).

• Example: alb.ingress.kubernetes.io/ssl-redirect: '443'- SSL redirect (ssl-redirect), if defined in an IngressGroup, affects all Ingresses within the group.
• When SSL redirect is enabled, all HTTP listeners are configured to redirect to HTTPS by default, ignoring other HTTP rules.

etc- alb.ingress.kubernetes.io/ip-address-type:

• Allows you to specify whether the ALB should use ipv4 or dualstack to support IPv4 and IPv6 traffic.

• Example: alb.ingress.kubernetes.io/ip-address-type: ipv4 or dualstack - ipv4: Configures the ALB to use only IPv4 addresses, meaning that the ALB handles IPv4 traffic exclusively.

• dualstack: The ALB will have both IPv4 and IPv6 addresses and can route traffic for both address types.

• alb.ingress.kubernetes.io/customer-owned-ipv4-pool:

  • Specifies a customer-owned IPv4 address pool for the ALB when using an Outpost environment.
  • Warning: This annotation cannot be changed. To change or restrict it, you must recreate the Ingress.
  • Example: alb.ingress.kubernetes.io/customer-owned-ipv4-pool: ipv4pool-coip-xxxxxxx

Reference

• Ingress annotations

---