EMD Blog

OIDC란 Open ID Connect의 약자로 일종의 인증 프로토콜이다. 이와 관련된 문서들을 보면 매커니즘이 OAuth2.0과 매우 비슷하다는 느낌을 받을 수 있는데 이는 OIDC가 OAuth2.0을 기반으로 하기 때문이다. 자세한 설명은 아래 문서 참고. https://www.samsungsds.com/kr/insights/oidc.html Github Actions에서 AWS에 접근하고자 할 때 AWS인증과 권한을 필요로 한다. 예를 들면 파이프라인에서 S3에 파일을 업로드 할 때나 ECR Private Repository Push 할 때가 그렇다. 이때 Github Actions에서는 다음처럼 인증을 수행할 수 있다. (repository) - name: Configure AWS Credenti..

Virtual Host를 위해 CloudFront 원본 요청 헤더에 호스트를 포함시키려면 레거시 캐시 설정에서 호스트 헤더 설정이 필요함. https://aws.amazon.com/ko/premiumsupport/knowledge-center/configure-cloudfront-to-forward-headers/ 원본 요청 헤더에 호스트를 포함 시켜서 ALB에 요청 시 ALB는 어떻게 호스트를 IIS로 전달할 것인지 고민 필요. 다음과 같은 방법을 조사해봐야함. ALB에 호스트기반 라우팅 설정 후 CloudFront의 헤더 호스트를 읽어 적절하게 라우팅 ALB에서도 요청 헤더에 호스트 정보를 담아 전달 1번의 경우 가능은 한 것으로 보임. 하지만 결국 Host에 따라 적절하게 콘텐츠를 반환해주는 것은 ..

EKS 사용시 적용할 수 있는 권한체계는 2가지가 있다. 하나는 Cluster에 적용하는 리소스 기반 정책과 IAM Role Service Account(IRSA)를 사용해 Cluster 내 Service Account에 IAM Role을 연동하는 OIDC 방식이 존재한다. Cluster에 적용해서 AWS 리소스에 접근하든, Service Account로 접근하든 AWS 리소스에 액세스 하는 것은 마찬가지인데 왜 둘이 나눠져 있는 것인지 의문이 들어 확인해보고 정리한다. EKS cluster를 생성할 때, Cluster가 AWS에 액세스 할 수 있도록 Cluster에 role을 지정할 수 있다. 아래 문서를 보면 Cluster 생성 시 AmazonEKSClusterPolicy 정책이 포함된 role을 지..

개요 온프레미스와 클라우드 간의 전용선을 구축하는 것은 상당히 많은 시간이 소요된다. 신규 증설 같은 경우는 최소 2주 이상은 소요되는 경우가 많은데, 이 때문에 시간을 넉넉하게 잡고 전용선 증설을 하는 것이 좋다. 하지만 전용선 증설에는 각 부서간의 합의와 업체간의 계약이 이루어져야 하기 때문에 시간을 맞추지 못해 곤란해지는 상황이 종종 발생하기도 한다. 만약 시간을 제대로 맞추지 못해 전용선 증설 일정이 틀어질 것 같다면 어떻게 해야할까? VPN 같은 것을 사용할 수도 있고 사내 정책에 따라 임시로 공인 IP를 매핑해 작업을 이어나갈 수 있을 것이다. 하지만 이런 상황도 힘들다고 하면 다른 전용선을 빌려쓰는 방법도 고려해볼 수 있다. 전용선을 빌려쓰는 방법은 두 가지를 고려할 수 있다. 1. 신규 V..

Private하게 구성해놓은 RDS를 외부에서 접근하고 싶을 때가 있다. 다른 DBMS는 SSH 터널링 옵션을 사용해서 쉽게 붙을 수 있지만 SQL Server는 직접 터널을 열어줘야 한다고 한다. RDS 구성 RDS는 따로 구성이 필요하지는 않지만 외부 액세스 허용을 Off로 해주는 것과 Bastion host로 부터 접근 가능하도록 방화벽은 설정해주어야 한다. Bastion Host 구성 제일 최저 사양의 VM을 RDS와 같은 VPC에 생성한다. 이때 Bastion Host는 외부에서도 접근 가능해야하기 때문에 Public 서브넷에 구성해야하며 외부 IP를 부여해주어야 한다. module "ec2_instance_bastion" { source = "terraform-aws-modules/ec2-in..

Windows Server도 AWS Session Manager를 통해 연결 가능함. 사전 구성 https://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/session-manager-prerequisites.html Windows Server 2012 ~ Windows Server 2019 (Session Manager는 2012 ~ 2019 버전만 지원함) SSM Agent 설치 아래 세 엔드포인트에 대한 443 아웃바운드 트래픽 허용 ec2messages.region.amazonaws.com ssm.region.amazonaws.com ssmmessages.region.amazonaws.com AWS CLI 1.16.12 버전 이상 설치 ..

IDC GCP Shared VPC ←—- (VPC Peering) —→ Other VPC 위처럼 구성했을 때 Other VPC에 대한 네트워크 대역들이 온프레미스에 전파가 안되고 있음. 문서상에서는 동적으로 경로를 전파(BGP로)한다고 적혀있기는 한데 전파가 안됨. 일단 VPC 에서 route 정보에 해당 네트워크 대역(Other VPC)이 등록은 되어 있음. 내용 확인해 보겠음. ========= 해결 됨 요약하면 다음과 같음. IDC Project A VPC Project B VPC 이렇게 구성하려할 때 IDC와 Project B VPC간 라우팅 정보는 수동으로 전파해야함. Peering 생성할 때 Project A > Project B로 커스텀 경로 내보내기..

현재 상황은 아래와 같음. ============================================================ - 현재 구축되어 있는 GCP의 네트워크(shared VPC 사용 중)와 IDC 센터는 인터커넥트로 연결되어 있음. - GCP 내에는 Cloud SQL이 비공개 IP로 구성되어 있으며, IDC에서 이 Cloud SQL로 접근해야하는 상황. - 하지만 IDC의 IP 대역은 172.17.0.0/16이기 때문에 GCP 비공개 서비스에 직접적으로 접근 불가.(GCP의 172.17.0.0/16 대역은 Docker 브리지로 예약) - 때문에 Proxy VM을 구축해서 IDC -> Proxy VM -> Cloud SQL 형태를 만드려고 함. - 여기서 Proxy VM은 MIG+자동복..

gcloud compute instance-groups managed rolling-action stop-proactive-update study-managed-instance-group \\ --zone=asia-northeast3-a gcloud compute instance-groups managed rolling-action stop-proactive-update 명령어가 MIG내 최대 인수턴스 개수에 어떤 영향을 미치는 지 궁금함. 그래서 GCP 케이스에 아래와 같은 내용으로 등록하였음. ==============[케이스 질문]================ 스테이트풀 구성 중 궁금한 점이 있어 문의드립니다. 처음에 아래와 같이 스테이트리스 인스턴스 그룹과 오토스케일링을 설정했습니다. ======..

Cloud 모니터링의 알림 채널을 Pub/Sub으로 설정해 알림 메세지를 게시하면 Cloud Functions에서 메세지 내용 확인 시 데이터가 암호화되어 있는 것을 볼 수 있다. 모니터링 알림 스키마 구조 https://cloud.google.com/monitoring/support/notification-options#pubsub 위 문서에서 중간쯤 보면 스키마 구조와 설명이 적혀있다. 하지만 메세지를 출력해보면 아래와 같이 나온다. (검은색으로 칠해진 부분은 base64 데이터이다.) 즉, 아래구조로 출력된다. ( Message ID와 Publish Time은 Pub/Sub에서 생성) { data : string, messageId: string, message_id : string, publish..