EKS 인증 인가
April 2024 (2135 Words, 12 Minutes)
인증 인가
자격증명에는 인증과 인가 그리고 Admission Control이 존재합니다.
쿠버네티스의 Admission Controller는 Kube-API 서버 레이어에서 동작하는 플러그인입니다. API 요청을 적용(즉, 오브젝트를 저장)하기 전에 요청을 가로채고, 해당 요청에 대해 특정 규칙 및 정책을 적용하는 역할을 합니다. 이를 통해 오브젝트가 클러스터의 기존 상태를 변경하거나 새로운 상태를 생성하는 것을 관리하거나 제어할 수 있습니다
- Authentication (인증)
- 이 단계에서는 사용자 또는 시스템의 신원이 확인됩니다. 즉, 요청이 누구로부터 왔는지 확인하는 과정입니다. 인증은 사용자 이름과 비밀번호, 토큰, 또는 디지털 인증서를 사용하여 신원을 확인할 수 있습니다. 쿠버네티스는 여러 인증 방법을 지원하며, 이는 클러스터 구성에 따라 다르게 설정될 수 있습니다.
- Authorization (권한 부여)
- 이 단계에서는 이미 인증된 사용자 또는 시스템이 요청한 작업을 수행할 권한이 있는지 확인합니다. 즉, 요청이 수행될 수 있는지를 결정하는 권한을 검사하는 단계입니다. 쿠버네티스에서는 Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC), Node authorization 등 다양한 권한 부여 방법을 제공합니다.
- Admission Control
- 이 단계는 인증 및 권한 부여를 거친 요청이 쿠버네티스 클러스터의 규칙 및 정책을 준수하는지 확인하는 단계입니다. 이 단계는 쿠버네티스 리소스가 실제로 생성, 수정, 삭제되기 전에 발생합니다. Admission Controllers는 이 단계를 처리하며, 특정 리소스에 대한 복잡한 기본값 설정, 리소스 사용량 제한, 네임스페이스의 수명주기 관리 등을 담당할 수 있습니다.
API 요청의 처리 과정에서 순차적으로 적용되는 세 가지 접근 제어 방식에 대해 설명해드렸습니다.
조금 더 이해하기 쉽게 설명드리자면
Authentication은 ‘누가 요청을 하였는가’를 확인하는 과정,
Authorization은 ‘요청자가 해당 작업을 수행할 권한이 있는가’를 확인하는 과정,
그리고 Admission Control은 ‘요청이 클러스터의 규칙 및 정책을 준수하는가’를 확인하는 과정
으로 이해할 수 있습니다.
이 세 가지 메커니즘은 쿠버네티스의 보안 및 접근 제어 구조의 핵심 요소라고 볼 수 있습니다.
Admission Control은 다음과 같은 방식으로 kube-apiserver에서 요청이 수신되기 전 webhook을 수행하는 과정입니다.
유저가 리소스 생성요청을할때, kube-apiserver가 admission controller에게 리뷰를 요청해 webhook 동작을 수행하고, 조건이 충족되었을경우 리소스를 생성합니다.
이 webhook에는 두가지 종류가 존재하는데요
-
Mutating Webhook Configuration
Mutating webhook은 API 요청에 대한 리소스를 수정할 수 있습니다. 즉, 이 웹훅은 API 요청이
ETCD에 저장되기 전에 리소스의 값을 변경할 수 있습니다. 예를 들어, 특정 Pod에 기본적으로 적용해야 하는 환경 변수, 레이블, 주석 등을 추가하는 데 사용합니다. -
Validating Webhook Configuration
Validating webhook은 API 요청을 수락 또는 거부하는 데 사용됩니다. 이 웹훅은 API 요청이
ETCD에 저장되기 전에 요청을 검사하고, 유효한지 검사합니다. 유효성 검사를 통과하지 못한 요청은 API 서버에 의해 거부되어 요청이ETCD에 저장되지 않습니다. 예를 들어, 사용자가 정의한 특정 규칙(예: Pod 이름이 특정 형식을 따르도록 하거나, 특정 레이블이 설정되어 있도록 하는 등)에 따라 요청의 유효성을 검사하는 데 사용할 수 있습니다.
이 두 종류의 웹훅은 mutating webhook이 먼저 실행된 후 validating webhook이 실행됩니다. 이렇게 하여 모든 변경 사항이 유효성 검사를 통과하도록 할 수 있습니다. 또한, 두 웹훅 모두 SSL/TLS를 통해 HTTPS를 사용하여 통신하며, 웹훅 서버에 대한 인증서를 쿠버네티스에 제공해야 합니다.
우리가 사용하는 kubectl 명령어도 kube config 기반의 api 요청이며, 정상적으로 인증/인가 과정을 거쳐 권한이 있을경우 원하는 명령어 수행과, 결과를 응답받을수 있습니다.
이제 Namespace별 서비스 어카운트와 권한 부여하는 테스트를 진행해보곘습니다.
# 네임스페이스(Namespace, NS) 생성 및 확인
kubectl create namespace dev-team
kubectl create ns infra-team
# 네임스페이스 확인
kubectl get ns
# 네임스페이스에 각각 서비스 어카운트 생성 : serviceaccounts 약자(=sa)
kubectl create sa dev-k8s -n dev-team
kubectl create sa infra-k8s -n infra-team
# 서비스 어카운트 정보 확인
kubectl get sa -n dev-team
kubectl get sa dev-k8s -n dev-team -o yaml | yh
kubectl get sa -n infra-team
kubectl get sa infra-k8s -n infra-team -o yaml | yh
그리고 해당 Service Account들을 마운트하는 pod들을 띄웁니다.
cat <<EOF | kubectl create -f -
apiVersion: v1
kind: Pod
metadata:
name: dev-kubectl
namespace: dev-team
spec:
serviceAccountName: dev-k8s
containers:
- name: kubectl-pod
image: bitnami/kubectl:1.28.5
command: ["tail"]
args: ["-f", "/dev/null"]
terminationGracePeriodSeconds: 0
EOF
cat <<EOF | kubectl create -f -
apiVersion: v1
kind: Pod
metadata:
name: infra-kubectl
namespace: infra-team
spec:
serviceAccountName: infra-k8s
containers:
- name: kubectl-pod
image: bitnami/kubectl:1.28.5
command: ["tail"]
args: ["-f", "/dev/null"]
terminationGracePeriodSeconds: 0
EOF
최초에 그림으로 표현했던것처럼 두개의 namespace에 각각의 service account를 마운트시킨 형태로 kubectl 명령어를 쓸 수 있는 pod를 띄운겁니다.
사실 serviceaccount에는 아무 role / clusterrole 을 선언하고 binding 해주지않았기때문에 권한이 없습니다.
다른 컨테이너에서 실행해도 마찬가지입니다.
cat <<EOF | kubectl create -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: role-dev-team
namespace: dev-team
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"]
EOF
cat <<EOF | kubectl create -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: role-infra-team
namespace: infra-team
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"]
EOF
# 롤바인딩 생성 : '서비스어카운트 <-> 롤' 간 서로 연동
cat <<EOF | kubectl create -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: roleB-dev-team
namespace: dev-team
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: role-dev-team
subjects:
- kind: ServiceAccount
name: dev-k8s
namespace: dev-team
EOF
cat <<EOF | kubectl create -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: roleB-infra-team
namespace: infra-team
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: role-infra-team
subjects:
- kind: ServiceAccount
name: infra-k8s
namespace: infra-team
EOF
이제 각 Serviceaccount에 사용할 역할인 Role과, SA - Role의 연결지점인 Rolebinding을 만들어줍니다. Clusterrole은 role의 namespace제한이 없는 Cluster 전역 권한으로 생각 할 수 있습니다.
dev 클러스터 권한을 부여한 pod에서는 다음과 같은 명령어들이 수행 가능합니다
하지만 같은 namespace 안에서의 자원 생성은 가능해도 타 namespace에 자원을 생성하거나 접근하는것은 불가능합니다.
vice versa 로 infra 파드에서도 dev team의 접근권한이 막히는것을 확인하실수 있을겁니다.
EKS의 인증 / 인가
EKS 인증/인가의 동작방식은 다음과 같은데
아주 간단한 도식화를 하면 다음과 같습니다.
인증은 AWS IAM
인가는 K8S RBAC으로 처리되는 로직입니다.
](images/AEWS/week6/EKS-authn-authz/Untitled9.png)
https://awskoreamarketingasset.s3.amazonaws.com/2022 Summit/pdf/T10S1_EKS 환경을 더 효율적으로 더 안전하게.pdf
eks에 kubectl 명령어를 수행할때 이루어지는 과정을 살펴보겠습니다.
aws eks get-token --cluster-name $CLUSTER_NAME | jq
명령어로 Token 값을 확인해봅니다.
expiration 시간이 있기때문에, 시간이 지나고나면 새로 갱신되는 Token 값을 확인 할 수 있습니다.
kubectl 명령을 날릴때 aws의 service endpoint로 통신하는 token 값은 다음과 같이 구성되어있습니다.
이후 EKS API는 Token Review를 Webhook Token Authenticator에 요청하여 AWS IAM의 해당 호출인증이 완료되면 User/Role에 대한 ARN을 반환합니다.
사실 온프레미스 쿠버네티스를 위주로해서 아직도 조금 생소한 개념이긴하지만, AWS 측에서 인증처리를 해준후 받는 응답을 다시 클라이언트 측에서 처리하면 된다고 이해하면 될것같습니다.
이제는 Kubernetes 내부의 RBAC에 맞는 인가 처리를 합니다.
이제 bastion2 노드에서 새로운 자격증명을 가진 user를 생성해보겠습니다.
aws 자격증명도 없고, kubernetes 자격증명도 없어 아무 응답을 받지 못하고있습니다.
aws 자격증명을 위해 IAM User를 생성해줍니다.
마지막에 create-access-key 명령어를 통해 AccessKeyID와 ScretAccessKey를 발급받아 bastion2 계정에 aws configure 작업을 진행합니다.
갖고있는 aws 자격증명을 통해 kubernetes config 키를 신규로 업데이트해줍니다.
이제 기존의 bastion 서버에서 접근하던것과 동일한 결과값들을 받을 수 있습니다.
그럼 이제 이발급받은 자격증명으로 쿠버네티스 시스템 안에서 이루어지는 과정을 살펴보겠습니다.
validating webhook config으로 aws-auth가 처리되는 과정은 다음과 같습니다.
aws-auth 가 이루어질때 참조하는 configmap 값은 다음과 같습니다.
신규로 생성한 testuser 유저가 mapUsers 항목에 배열로 들어가있는것을 확인 할 수 있었습니다.
eksctl 명령어로 system:master 그룹을 만들어 testuser 계정을 넣었습니다,
eksctl create iamidentitymapping --cluster $CLUSTER_NAME --username testuser --group system:masters --arn arn:aws:iam::$ACCOUNT_ID:user/testuser
이렇게 Group을 통해 system:masters 그룹이 clusterrole 설정으로 모든 권한이 부여되어있는것을 확인 할 수 있습니다.
Group이라는 단위는 처음보는 단위였는데 RBAC을 크게 관리하려면 이런식의 계정관리도 중요할거같다는 생각이 드는군요
이제 생성된 kube config 키를 비교해봐도 bastion2 의 kubeconfig는 testuser로 요청을 처리한다는 내용을 확인 할 수 있네요.
IRSA
irsa는 kubernetes에서 aws의 iam을 이용하여 AWS의 컴포넌트를 제어할수있는 RBAC 부여 방법입니다.
기존에 EC2 instance profile이라는 인스턴스단위의 AWS 인증/인가가 있었지만, 최소 권한 원칙에 어긋나기때문에 나온 개념이라고 이해하면 될거같습니다.
실제로 IRSA가 나온 이후로, Pod Identity 개념이 새로 출시되긴했는데 각 특성을 알아보도록 하겠습니다.
# 파드1 생성
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
name: eks-iam-test1
spec:
containers:
- name: my-aws-cli
image: amazon/aws-cli:latest
args: ['s3', 'ls']
restartPolicy: Never
automountServiceAccountToken: false
terminationGracePeriodSeconds: 0
EOF
# 확인
kubectl get pod
kubectl describe pod
# 로그 확인
kubectl logs eks-iam-test1
# 파드1 삭제
kubectl delete pod eks-iam-test1
cloudtrail 에서도 확인이 가능합니다.
{
...
"userIdentity": {
"type": "AssumedRole",
"principalId": "xxxx",
"arn": "arn:aws:sts::111122223333:assumed-role/eksctl-eks-oidc-demo-nodegroup-ng-NodeInstanceRole-xxxx/xxxx",
"accountId": "111122223333",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "xxxx",
"arn": "arn:aws:iam::xxxx:role/eksctl-eks-oidc-demo-nodegroup-ng-NodeInstanceRole-xxxx",
"accountId": "111122223333",
"userName": "eksctl-eks-oidc-demo-nodegroup-ng-NodeInstanceRole-xxxx"
},
"webIdFederationData": {},
"attributes": {
"creationDate": "2021-12-04T14:54:49Z",
"mfaAuthenticated": "false"
},
"ec2RoleDelivery": "2.0"
}
},
"eventTime": "2021-12-04T15:09:20Z",
"eventSource": "s3.amazonaws.com",
"eventName": "ListBuckets",
"awsRegion": "us-east-2",
"sourceIPAddress": "192.0.2.1",
"userAgent": "[aws-cli/2.4.5 Python/3.8.8 Linux/5.4.156-83.273.amzn2.x86_64 docker/x86_64.amzn.2 prompt/off command/s3.ls]",
"errorCode": "AccessDenied",
"errorMessage": "Access Denied",
"requestParameters": {
"Host": "s3.us-east-2.amazonaws.com"
},
...
}
Json 형태의 데이터를 뽑아보면 상세한 내용을 확인 할 수 있습니다.
# 파드2 생성
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
name: eks-iam-test2
spec:
containers:
- name: my-aws-cli
image: amazon/aws-cli:latest
command: ['sleep', '36000']
restartPolicy: Never
terminationGracePeriodSeconds: 0
EOF
# aws 서비스 사용 시도
kubectl exec -it eks-iam-test2 -- aws s3 ls
# 페이로드 : OAuth2에서 쓰이는 aud, exp 속성 확인! > projectedServiceAccountToken 기능으로 토큰에 audience,exp 항목을 덧붙힘
## iss 속성 : EKS OpenID Connect Provider(EKS IdP) 주소 > 이 EKS IdP를 통해 쿠버네티스가 발급한 토큰이 유요한지 검증
{
"aud": [
"https://kubernetes.default.svc" # 해당 주소는 k8s api의 ClusterIP 서비스 주소 도메인명, kubectl get svc kubernetes
],
"exp": 1716619848,
"iat": 1685083848,
"iss": "https://oidc.eks.ap-northeast-2.amazonaws.com/id/F6A7523462E8E6CDADEE5D41DF2E71F6",
"kubernetes.io": {
"namespace": "default",
"pod": {
"name": "eks-iam-test2",
"uid": "10dcccc8-a16c-4fc7-9663-13c9448e107a"
},
"serviceaccount": {
"name": "default",
"uid": "acb6c60d-0c5f-4583-b83b-1b629b0bdd87"
},
"warnafter": 1685087455
},
"nbf": 1685083848,
"sub": "system:serviceaccount:default:default"
}
# 파드2 삭제
kubectl delete pod eks-iam-test2
IRSA 적용
출처 : https://dev.to/aws-builders/auditing-aws-eks-pod-permissions-4637
다음과 같은 과정으로 IRSA 부여가 됨을 확인해봅니다.
# Create an iamserviceaccount - AWS IAM role bound to a Kubernetes service account
eksctl create iamserviceaccount \
--name my-sa \
--namespace default \
--cluster $CLUSTER_NAME \
--approve \
--attach-policy-arn $(aws iam list-policies --query 'Policies[?PolicyName==`AmazonS3ReadOnlyAccess`].Arn' --output text)
# 확인 >> 웹 관리 콘솔에서 CloudFormation Stack >> IAM Role 확인
# aws-load-balancer-controller IRSA는 어떤 동작을 수행할 것 인지 생각해보자!
eksctl get iamserviceaccount --cluster $CLUSTER_NAME
# Inspecting the newly created Kubernetes Service Account, we can see the role we want it to assume in our pod.
kubectl get sa
kubectl describe sa my-sa
Name: my-sa
Namespace: default
Labels: app.kubernetes.io/managed-by=eksctl
Annotations: eks.amazonaws.com/role-arn: arn:aws:iam::911283464785:role/eksctl-myeks-addon-iamserviceaccount-default-Role1-1MJUYW59O6QGH
Image pull secrets: <none>
Mountable secrets: <none>
Tokens: <none>
Events: <none>
이렇게 Service Account에 IAM 을 생성해 rolearn을 부여해줍니다.
# 파드3번 생성
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
name: eks-iam-test3
spec:
serviceAccountName: my-sa
containers:
- name: my-aws-cli
image: amazon/aws-cli:latest
command: ['sleep', '36000']
restartPolicy: Never
terminationGracePeriodSeconds: 0
EOF
# 되는 것고 안되는 것은 왜그런가?
kubectl exec -it eks-iam-test3 -- aws s3 ls
kubectl exec -it eks-iam-test3 -- aws ec2 describe-instances --region ap-northeast-2
kubectl exec -it eks-iam-test3 -- aws ec2 describe-vpcs --region ap-northeast-2
생성된 pod에 하루동안 사용이 가능한 aws iam token이 mount 되어있는것을 확인 할 수 있습니다.
이 token은 mutating webhook으로 토큰을 mount하는 과정이 들어가있습니다.
kubectl get mutatingwebhookconfigurations pod-identity-webhook -o yaml | kubectl neat | yh
EKS Pod Identity
EKS Pod Identity는 기존의 IRSA보다 더 발전된 형태의 pod 자격증명으로 기존의 단점들을 해결하여 나온 형태의 자격증명입니다.
IRSA는 기존에 사용하던 역할, 신뢰정책등에 대한 수정이 번거로우며 신뢰정책에 * 을 사용했던것들, 사용성 등에 대한 annotaion/role의 신뢰정책
고민들을 해결해주고 있습니다.
](images/AEWS/week6/EKS-authn-authz/Untitled28.png)
설치
# 버전 확인
ADDON=eks-pod-identity-agent
aws eks describe-addon-versions \
--addon-name $ADDON \
--kubernetes-version 1.28 \
--query "addons[].addonVersions[].[addonVersion, compatibilities[].defaultVersion]" \
--output text
# 설치
aws eks create-addon --cluster-name $CLUSTER_NAME --addon-name eks-pod-identity-agent
# 혹은
eksctl create addon --cluster $CLUSTER_NAME --name eks-pod-identity-agent --version 1.2.0
- podidentityassociation 설정
eksctl create podidentityassociation \
--cluster $CLUSTER_NAME \
--namespace default \
--service-account-name s3-sa \
--role-name s3-eks-pod-identity-role \
--permission-policy-arns arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess \
--region $AWS_REGION
이렇게 s3-sa 라는 service account에 권한부여한것을 확인했습니다.
aws console에서도 똑같이 부여된 권한들을 확인이 가능합니다.
# 서비스어카운트, 파드 생성
kubectl create sa s3-sa
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
name: eks-pod-identity
spec:
serviceAccountName: s3-sa
containers:
- name: my-aws-cli
image: amazon/aws-cli:latest
command: ['sleep', '36000']
restartPolicy: Never
terminationGracePeriodSeconds: 0
EOF
kubectl exec -it eks-pod-identity -- aws s3 ls
kubectl exec -it eks-pod-identity -- env | grep AWS
pod identity 리소스 삭제
eksctl delete podidentityassociation --cluster $CLUSTER_NAME --namespace default --service-account-name s3-sa
kubectl delete pod eks-pod-identity
kubectl delete sa s3-sa
Keycloak 배포하기
keycloak 을 테라폼으로 배포하기를 보고, 따라해본 EKS 상 Helm으로 배포하기입니다.
추가적인 셋팅들이 19버전부터 꽤 불편해 18버전을 고정으로 사용해두고있었습니다.
EKS위에서 RDS가 아닌 Postgresql POD 를 생성해 설치하는 과정입니다.
values.yaml
cat <<EOT > keycloak-values.yaml
clusterDomain: cluster.local
extraEnv: |
- name: KEYCLOAK_USER
value: keycloak
- name: KEYCLOAK_PASSWORD
value: password
- name: PROXY_ADDRESS_FORWARDING
value: "true"
global:
storageClass: gp3
image:
tag: 18.0.2-debian-11-r9
postgresql:
persistence:
enabled: true
size: 10Gi
postgresqlDatabase: keycloak
postgresqlPassword: password
postgresqlPostgresPassword: password
postgresqlUsername: keycloak
EOT
helm repo add bitnami https://charts.bitnami.com/bitnami
helm upgrade --install --namespace keycloak --create-namespace keycloak bitnami/keycloak -f keycloak-values.yaml
cat <<EOT > keycloak-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: keycloak-ingress
namespace: keycloak
annotations:
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/target-type: ip
alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'
alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN
alb.ingress.kubernetes.io/success-codes: 200-399
alb.ingress.kubernetes.io/load-balancer-name: myeks-ingress-alb
alb.ingress.kubernetes.io/group.name: study
alb.ingress.kubernetes.io/ssl-redirect: '443'
kubernetes.io/ingress.class: "alb"
spec:
rules:
- host: sso.$MyDomain
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: keycloak
port:
number: 80
tls:
- hosts:
- sso.montkim.org
EOT
kubectl apply -f keyclaok-ingress.yaml
배포를 한 후에는 DB pod와 인증처리를 해주는 pod를 구동한것이 확인됩니다.
위에 설정으로 접속할경우 ACM으로 인증받은 HTTPS 통신을 통해
배포에 성공한것을 볼 수 있습니다.
흔히 쿠버네티스에서 사용되는 기본적인 모니터링 솔루션들이나 기타 Gitlab 등 OIDC Provider 에 대해 깊게 이해한다면 이런 Keycloak을 통한 통한 접근제어를 관리할수있습니다.
인증/인가 과정에서 사용되는 오픈소스인 keycloak을 이용해서 쿠버네티스의 접근제어도 설정이 가능하다고 알고있습니다.
https://www.youtube.com/watch?v=owaK-V2MAjU
언젠간 기회가 된다면 이런 설정들을 통해 더 퀄리티 높은 서버의 인증/인가 처리를 구성해보고싶다는 생각이 듭니다.