제로빅의 블로그

AZ-104 핸즈온 : Microsoft Entra ID ID 관리 P3 - Azure Policy ３

zerobig-k8s — Mon, 4 Aug 2025 08:02:01 +0900

핸즈온2 : Azure Policy와 DevOps 연계 – 배포 전 Azure Policy 준수 검사

Azure DevOps 파이프라인 내에서 Azure Policy 준수 여부를 자동으로 확인하고, 비준수 시 배포를 중단하는 보안/거버넌스 실습을 시행해 보자.

사전 준비 사항

항목	설명
Azure DevOps 프로젝트	Azure DevOps 프로젝트가 있어야 하며 Service Connection 구성 필요 프로젝트 만들기 참조 및 Service Connection 참조
Azure Policy 정의	하나 이상의 정책 정의 및 할당 필요 (예: NSG에 모든 포트를 열지 말 것)
Service Principal 권한	DevOps의 Service Connection에 Policy Insights Reader 권한 필요
Azure CLI 설치	DevOps Agent에 설치되어 있어야 함

Azure CLI 환경에서 진행할 예정이니, Azure SA 업무 환경 구성 - Part 1, Azure SA 업무 환경 구성 - Part 2를 참조하여 환경을 작업 구성한다.

예시 시나리오

배포 대상 region: eastus (정책에 의해 차단됨)
policyAssignmentName과 subscriptionId를 기준으로 정책 상태 쿼리 → 파이프라인에서 정책 위반 시 즉시 배포 중단
az policy state list 명령으로 비정상 리소스 탐지 → exit 1로 배포 중단

이 시나리오는 단순한 실습을 넘어 클라우드 거버넌스 자동화(Governance as Code), 보안 및 거버넌스 조기 검증(Shift-Left）, DevOps와 정책의 통합(Policy-as-Code)이라는 큰 의미를 가진다.

1. Azure Policy 정의

1. 먼저 "Allowed locations" 정책의 Policy Definition ID를 확인한다.

az policy definition list --query "[?displayName=='Allowed locations'].{name:name, id:id}" -o table

Azure-HandsOn-Demo# az policy definition list --query "[?displayName=='Allowed locations'].{name:name, id:id}" -o table
Name
------------------------------------
e56962a6-4747-49cd-b67b-bf8b01975c4c

2. koreacentral만 리소스 배포 허용하는 내용의 Azure Policy를 할당한다.

az policy assignment create \
  --name 'allow-koreacentral-only' \
  --display-name 'Allow only koreacentral location' \
  --policy <YOUR_Policy_Definition_ID> \
  --params '{ "listOfAllowedLocations": { "value": ["koreacentral"] } }' \
  --scope "/subscriptions/<YOUR_SUBSCRIPTION_ID>"

Azure-HandsOn-Demo# az policy assignment create \
> --name 'allow-koreacentral-only' \
> --display-name 'Allow only koreacentral location' \
> --policy e56962a6-4747-49cd-b67b-bf8b01975c4c \
> --params '{ "listOfAllowedLocations": { "value": ["koreacentral"] } }' \
> --scope "/subscriptions/3864xxxx-xxxx-xxxxx-xxxx-4a08ac96xxxx"
Readonly attribute scope will be ignored in class <class 'azure.mgmt.resource.policy.v2021_06_01.models._models_py3.PolicyAssignment'>
{
  "description": null,
  "displayName": "Allow only koreacentral location",
  "enforcementMode": "Default",
  "id": "/subscriptions/3864xxxx-xxxx-xxxxx-xxxx-4a08ac96xxxx/providers/Microsoft.Authorization/policyAssignments/allow-koreacentral-only",
  "identity": null,
  "location": null,
  "metadata": {
    "createdBy": "6b1063b6-302b-4141-afe1-82917f102a7b",
    "createdOn": "2025-08-03T08:46:06.4521179Z",
    "updatedBy": null,
    "updatedOn": null
  },
  "name": "allow-koreacentral-only",
  "nonComplianceMessages": null,
  "notScopes": null,
  "parameters": {
    "listOfAllowedLocations": {
      "value": [
        "koreacentral"
      ]
    }
  },
  "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/e56962a6-4747-49cd-b67b-bf8b01975c4c",
  "scope": "/subscriptions/3864xxxx-xxxx-xxxxx-xxxx-4a08ac96xxxx",
  "systemData": {
    "createdAt": "2025-08-03T08:46:06.220901+00:00",
    "createdBy": "zerobig.kim@gmail.com",
    "createdByType": "User",
    "lastModifiedAt": "2025-08-03T08:46:06.220901+00:00",
    "lastModifiedBy": "zerobig.kim@gmail.com",
    "lastModifiedByType": "User"
  },
  "type": "Microsoft.Authorization/policyAssignments"
}
Azure-HandsOn-Demo#

2. Azure DevOps 파이프라인 구성 (YAML)

Service Connection 생성

1. 프로젝트 만들기 참여 새 프로젝트를 생성한다.

2. 좌측 하단의 Project Settings > Service connections을 선택하고 Create service connection을 선택한다.

3. New service connection에서 Azure Resource Manager 체크하고 Next를 선택한다.

4. New Azure service connection 에서 대상 구독을 선택하고 로그인 수행 후, Service Connection Name을 입력하고 하단 Security의 Grant access permission to all pipelines를 체크하고 Save 한다.

Azure Repos 구성

Repos > Files에서 화면 하단에 Initialize를 클릭하여 초기화 한다.

Azure Pipeline 구성

1. 좌측 하단의 Pipelines을 선택 후 Create Pipeline을 선택한다.

2. Connect 화면에서 Azure Repos GIT을 선택한다.

3. Select 화면에서 앞에서 생성한 리포지토리를 선택한다. 예) PRJ-ADO-AzurePolicy-Demo

4. Configure 화면에서 Starter pipeline을 선택한다.

5. 기본 제공되는 코드를 삭제하고 다음 코드를 붙여넣는다.

trigger:
  - main

pool:
  vmImage: 'ubuntu-latest'

variables:
  subscriptionId: '3864b016-4594-40ad-a96b-4a08ac96b537'
  azureRegion: 'eastus'  # koreacentral이 아니므로 정책 위반 예상
  policyAssignmentName: 'allow-koreacentral-only'

steps:
- task: AzureCLI@2
  displayName: 'Check Azure Policy Compliance'
  inputs:
    azureSubscription: 'Azure-MVP-Subscription'
    scriptType: 'bash'
    scriptLocation: 'inlineScript'
    inlineScript: |
      echo "INFO: Checking Azure Policy compliance for assignment: $(policyAssignmentName)"
      
      # az cli 쿼리를 통해 지난 하루 전에 비준수 리소스의 '개수'만 직접 가져오기
      # 지난 30일간 조회
      NON_COMPLIANT=$(az policy state list \
        --subscription ${{ variables.subscriptionId }} \
        --policy-assignment "allow-koreacentral-only" \
        --from $(date -u -d '1 days ago' +%Y-%m-%dT%H:%M:%SZ) \
        --to $(date -u +%Y-%m-%dT%H:%M:%SZ) \
        --query "[?complianceState=='NonCompliant']" \
        --output json)
      
      echo "$NON_COMPLIANT" > policy_check.json
      COUNT=$(jq length policy_check.json)
      
      echo "INFO: Non-compliant resource count: $COUNT"
      
      # 개수가 0보다 큰지 비교하여 파이프라인 실패 처리
      if [ "$COUNT" -gt 0 ]; then
        echo "Azure Policy violation detected. Blocking deployment."
        exit 1
      else
        echo "Azure Policy compliance check passed. Proceeding with deployment."
      fi

8행 <YOUR_SERVICE_CONNECTION_NAME>를 자신의 구독 ID로 대체한다.
12행 근처에 Settings를 클릭하면 Azure CLI assistant 창이 전시된다.

5. 우측 상단의 Save and run을 선택하고 다음 화면에서 다시 Save and run을 선택한다.

6. Authorize resource를 선택하고 우측 상단에 Run new를 선택하여 다시 파이프라인을 실행한다.

3. 실행 결과 확인

파이프라인을 클릭하여 Job을 선택한다.

실행 결과 로그를 확인한다.

54 행 정책 체크(az policy state list) 수행 결과 정책 위반을 감지하고 exit 1로 배포가 중단됨을 확인한다.

AZ-104 핸즈온 : Microsoft Entra ID ID 관리 P3 - Azure Policy 2

zerobig-k8s — Mon, 21 Jul 2025 07:53:21 +0900

핸즈온1 : Advisor 보안 권고사항의 Azure Policy 연계

이전 글에서 우리는 Azure Advisor에 대하여 살펴보고 핸즈온을 수행해봤다. Advisor에 대해 생소한 독자는 이전 글을 참조한다.

Azure Advisor와 Azure Policy는 Azure 환경의 거버넌스와 최적화를 위한 핵심 서비스이며, 상호 보완적인 관계를 가진다. Azure Advisor가 "무엇을 개선해야 할지"에 대한 정보와 통찰을 제공한다면, Azure Policy는 그 통찰을 기반으로 "어떻게 개선하고, 향후 그러한 문제가 발생하지 않도록 강제할 것인지"에 대한 자동화된 메커니즘을 제공한다. 예를 들어, Azure Advisor가 "특정 지역에 보안 그룹이 열려 있어 보안 위험이 있다”라는 권장 사항을 제시하면, Azure Policy는 해당 지역에 특정 포트가 열린 보안 그룹 생성을 원천적으로 차단하거나, 이미 존재하는 경우 자동으로 수정하는 정책을 배포할 수 있다. 즉, Advisor는 문제 발견에, Policy는 문제 해결 및 예방에 초점을 맞춘다.

이번 핸즈온에서는 Advisor상에 보안 관련 권고사항이 발생했고 이에 대해 Azure Policy를 활용하여 조치하는 내용에 관한 것이다.

다음과 같이 All network ports should be restricted on network security groups associated to your virtual machine 라는 권고사항이 발생했다고 가정한다.

참고로 Microsoft Defender for Cloud에서도 동일한 내용의 보안 권고사항이 발생하는 것을 확인할 수 있다.

이는 Advisor의 보안 권고사항이 근본적으로 Microsoft Defender for Cloud의 보안 권고사항으로부터 근원하고 있기 때문이다. 하지만 두 서비스의 목적과 범위가 다르기 때문에 사용자는 약간의 차이를 경험할 수 있습니다. 이는 여러 사유로 기인하지만 기본적으로 Advisor에서는 선별된 뷰(View)를 확인하는 것이기 때문이다. 두 권고사항의 차이점은 대략 다음과 같다.

항목	Azure Advisor	Microsoft Defender for Cloud
목적	단순 권고사항 제공, 빠른 조치 유도	정밀한 보안 진단과 보안 점수 기반 지속 관리
표시되는 항목 수	제한적, 요약된 권고	실시간 위협 탐지, 정책 기반 취약점 진단 포함
기술 심도	낮음 (비전문가도 보기 쉽게 제공)	높음 (보안 엔지니어 중심의 기술적 권고 포함

이제 핸즈온을 진행해 보자.

1. Azure Advisor 권고사항 확인

2. 해당 권고사항이 적용된 가상 머신 및 네트워크 보안 그룹을 확인한다. 이 정보는 정책을 적용할 범위를 결정한다.

2. 사용자 지정 정책 정의 생성

1. Azure Portal에서 Policy를 검색하여 선택한다.

2. Definitions를 선택하고 + Policy definition을 클릭한다.

3. 다음 예시 정보를 선택 및 입력한다.

Definition location: 적용 범위 선택 (구독)
Name: Restricting Virtual Machine NSG Inbound Ports
Description: Deny inbound traffic on specific ports on the NSG associated with the virtual machine.
Category: Network
POLICY RULE: 아래 JSON 코드를 붙여넣는다. 이 코드는 RDP (3389) 및 SSH (22) 포트에 대한 인바운드 트래픽을 거부하는 정책을 정의한다. 필요에 따라 다른 포트를 추가하거나 제거할 수 있다.

{
  "mode": "All",
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.Network/networkSecurityGroups/securityRules"
        },
        {
          "field": "Microsoft.Network/networkSecurityGroups/securityRules/access",
          "equals": "Allow"
        },
        {
          "field": "Microsoft.Network/networkSecurityGroups/securityRules/direction",
          "equals": "Inbound"
        },
        {
          "anyOf": [
            {
              "field": "Microsoft.Network/networkSecurityGroups/securityRules/destinationPortRange",
              "equals": "3389"
            },
            {
              "field": "Microsoft.Network/networkSecurityGroups/securityRules/destinationPortRange",
              "equals": "22"
            }
          ]
        }
      ]
    },
    "then": {
      "effect": "Deny"
    }
  },
  "parameters": {}
}

mode: 정책이 평가되는 방식을 지정한다. All은 모든 리소스 유형을 평가한다.
policyRule: 정책의 조건을 정의한다.
- if: 조건 블록이다.
  - allOf: 모든 조건이 충족되어야 한다.
    - field: 평가할 속성을 지정한다. 여기서는 NSG 보안 규칙의 속성을 확인한다.
    - equals: 속성 값이 지정된 값과 일치하는지 확인한다.
- then: 조건이 충족될 때 수행할 작업을 지정한다.
  - effect: 작업을 지정한다. Deny는 작업을 거부한다.
parameters: 정책에 전달할 수 있는 매개변수를 정의한다. 이 예제에서는 매개변수가 없다.

4. Save를 클릭한다.

3. 정책 할당

1. Azure Portal에서 Policy를 검색하여 선택한다.

2. Assignments를 선택하고 Assign policy를 클릭한다.

3. Scope에서 대상 VM이 배포된 구독 및 리소스 그룹을 선택한다.

4. Policy definition에서 위에서 생성한 정책(Restricting Virtual Machine NSG Inbound Ports)을 선택한다.

5. Remediation을 구성하여 기존의 비규격 리소스를 수정할지 여부를 결정한다.

6. Non-compliance message 입력창에 다음 메시지를 입력한다.

Security policy violation: Inbound traffic to RDP (3389) or SSH (22) ports is not allowed on Network Security Groups for virtual machines. These ports are restricted for security hardening.

DeployIfNotExists 효과를 사용하면 기존 리소스를 자동으로 수정할 수 있다.

7. Review + create를 클릭한 다음 Create를 클릭한다.

4. 정책 준수 확인

1. Azure Portal에서 Policy를 검색하여 선택한다.

2. Compliance를 선택한다.

3. 할당된 정책을 선택하여 준수 상태를 확인한다.

위에서 생성 및 할당한 정책의 Compliance 여부가 체크된 것을 확인할 수 있다.

Compliant 리소스는 정책을 준수하는 리소스이다.
Non-compliant 리소스는 정책을 준수하지 않는 리소스이다.

4. Non-compliant 리소스가 있는 경우, 정책 정의에 따라 수정 작업을 수행하거나 리소스를 수정해야 한다.

5. 정책 테스트

이제 정책이 올바르게 적용되었는지 확인하기 위해 테스트를 수행한다.

1. 먼저 기존 RDP 허용 정책이 존재하는지 확인 후 존재한다면 제거한다.

2. RDP 허용을 위한 Inbound port rule을 생성한다.

3. Add를 클릭하자 마자 보안 규칙 생성 실패에 대한 팝업 메시지가 전시됨을 확인한다.

보안 규칙 'AllowAnyRDPInbound'를 생성하지 못했습니다. 오류: 정책에 따라 'AllowAnyRDPInbound' 리소스가 허용되지 않았습니다. 이유: '보안 정책 위반: 가상 머신의 네트워크 보안 그룹에서 RDP(3389) 또는 SSH(22) 포트로의 인바운드 트래픽이 허용되지 않습니다. 이러한 포트는 보안 강화를 위해 제한됩니다.' 정책 리소스 ID에 대한 오류 세부 정보를 참조하세요.

6. VM 접속 모범사례

그렇다면, 이러한 실무 환경에서 해당 VM에 접속하기 위한 Best Practice는 무엇일까? 일반적인 방법 3가지 정도를 정리해 보면,

Azure Bastion
- 가장 권고된다. 보안성, 편리성, 관리 용이성 측면에서 탁월하다. → 대부분의 경우 (특히 작은 규모 또는 특정 VM에 대한 관리):

Jumpbox 서버
실무에서는 PaaS 서비스인 Azure Bastion의 비용 이슈로 Jumpbox 서버를 대체하여 구성하는 경우가 있다. 그러나 Jumpbox 서버데 대한 추가 관리 공수가 발생하고 Single Point of Failure 즉, 장애 시 리소스 접근에 어려움이 발생하게 된다.

JIT VM Access
- Microsoft Defender for Cloud를 이미 사용하고 있고, 짧은 시간 동안만 접근을 허용하는 유연성이 필요한 경우에 매우 유용하다. → 보안 자동화 및 필요에 따른 임시 접근 제어
- JIT VM 액세스에 대한 자세한 설명은 여기를 참고한다.
VPN Gateway
- 온프레미스 네트워크와 Azure 클라우드를 안전하게 연결해야 한다면 필수적이다. → 엔터프라이즈 규모의 통합된 네트워크 접근:

결론적으로, Azure Policy를 통해 RDP/SSH 직접 접속을 차단한 후에는 Azure Bastion 또는 JIT VM Access를 사용하는 것이 가장 일반적이고 권장되는 실무 접근 방식이다. VPN은 더 넓은 네트워크 통합 시나리오에서 고려된다.

다음 편에서는 Azure DevOps와 연계한 핸즈온을 시행해 보자.

다음 편에서 계속

AZ-104 핸즈온 : Microsoft Entra ID ID 관리 P3 - Azure Policy 1

zerobig-k8s — Sun, 13 Jul 2025 10:49:54 +0900

Azure Policy는 클라우드 환경에서 거버넌스를 구현하고 규정 준수를 보장하는 데 필수적이다. 이 블로그는 Azure Policy의 기본 개념부터 실제 실무 환경에 적용하는 핸즈온 실습까지 단계별로 안내하여 독자들이 Azure 환경을 효율적으로 관리하고 최적화하는 데 도움을 줄 것이다. 특히 이번 편에서도 Azure Advisor와 연계한 내용으로 구성하여 실무에서 필요한 지식을 습득할 수 있도록 구성했다. 전체 컨텐츠의 분량 및 개인 여건상 2~3개의 모듈로 나누어 게시하고자 한다.

Azure Policy의 이해

1. 기본 개념

Azure Policy 공식 문서는 방대하지만, 실무적인 관점에서 그 핵심을 요약하면 "클라우드 환경의 규칙을 정의하고, 이를 자동으로 평가하며, 나아가 강제하거나 수정하는 중앙 거버넌스 도구" 라고 정의할 수 있다.

단순히 '무엇을 할 수 없다'는 통제를 넘어, 조직의 클라우드 환경이 일관되고, 안전하며, 비용 효율적으로 운영되도록 보장하는 '자동화된 가드레일' 역할을 수행한다.

2. 역할

Azure Policy의 역할은 다음과 같은 실무 문제를 해결하는 데 있다.

비용 관리 (Cost Management): "개발자가 실수로 비싼 GPU 가상머신을 테스트용으로 배포하는 것을 막고 싶다."
보안 강화 (Security): "모든 스토리지 계정은 암호화된 연결(HTTPS)만 허용해야 하고, DB는 공용 IP를 가지면 안 된다."
리소스 일관성 (Consistency): "모든 리소스에는 비용 추적을 위해 'Owner'와 'CostCenter' 태그가 반드시 붙어 있어야 한다."
규정 준수 (Compliance): "우리 회사의 모든 데이터는 국내(한국 중부, 남부) 리전(Region)에만 저장되어야 한다."

이러한 규칙들을 담당자가 일일이 검사하는 것이 아니라, Policy가 24시간 자동으로 감시하고 조치할 수 있다.

3. 기본 구성 요소

구성요소	설명	비고
정책 정의 (Policy Definition)	정책의 규칙과 효과를 정의한 JSON 형식의 문서	기본 제공 정책: '허용되는 위치 (Allowed locations)'
이니셔티브 정의 (Initiative Definition)	여러 개의 정책 정의를 묶은 정책 집합	관리 간소화 목적
할당 (Assignment)	정책 또는 이니셔티브를 구독, 리소스 그룹 또는 관리 그룹 수준에 할당	'개발팀 리소스 그룹'에 '허용되는 위치' 정책을 할당한다.
파라미터 (Parameters)	정책 정의의 유연성을 높이기 위한 입력 값	허용되는 위치 목록
효과 (Effect)	정책이 감지한 위반 사항에 대해 어떤 조치를 취할지 결정	Deny, Audit, Append, DeployIfNotExists

4. 정책 적용 방식

리소스 배포 시점에 정책이 적용되어 조건을 위반하면 차단됨 (Deny)
기존 리소스에 대해서도 감사(Audit) 가능
자동 수정(DeployIfNotExists) 등을 통해 리소스를 기준에 맞게 구성 가능

5. 정책의 유형

유형	설명	비고
Built-in	Microsoft가 제공하는 사전 정의된 정책	위치 제한, 태그 필수, NSG 규칙 제한 등
Custom	조직 요건에 맞게 사용자 정의	특정 태그 값만 허용, 특정 SKU만 사용 가능
Initiative (정책 집합)	여러 정책을 묶어 관리	NIST, ISO 규정 등 준수 패키지

6. 정책의 주요 효과

효과	설명	비고
Audit	정책 위반 여부만 평가	"미준수 리소스 식별만"
Deny	정책 위반 리소스 배포 차단	"허용 위치 외 리소스 생성 금지"
Disabled	정책 비활성화	테스트 또는 예외 처리
Append	속성 추가 (ex: 태그 삽입)	"배포 시 자동으로 costCenter 태그 추가"
DeployIfNotExists	조건 충족 시 리소스 자동 배포	"Defender 비활성 VM에 자동 Agent 설치"

7. 활용 예시

시나리오	적용 정책 예시	효과
모든 리소스는 koreacentral에만 배포	allowed-locations	Deny
NSG 인바운드 규칙에서 Any 차단	Audit NSG with broad rules	Audit
태그 누락 리소스 자동 수정	Add tag if missing	DeployIfNotExists

8. 적용 절차 Best Practice

Audit → Deny 순서로 점진적 적용
이니셔티브로 정책을 모듈화하고 관리 용이성 확보
정책 위반 원인 분석을 위해 Activity Log와 연동
리소스 태그나 리전 같은 표준화 항목부터 적용

이제 Azure Policy에 대해 이해가 되었으니 다음 편부터는 실제 핸즈온을 수행하가며 익혀보자. 핸즈온의 내용은 단순하게 Azure Policy 자체만의 내용이 아닌 Advisor 및 Azure DevOps를 연계한 내용으로 구성하고자 한다.

핸즈온을 원활하게 수행하기 위해서는 Azure SA 업무 환경 구성 - Part 1, Azure SA 업무 환경 구성 - Part 2를 참조하여 환경을 작업 구성한다. 이는 단순한 환경 준비를 넘어 실제 실무에서 Azure 아키텍트 및 엔지니어로서 효율적인 업무를 수행하기 위한 최적화된 업무 환경 구성에 대한 가이드 이다.

다음 편에서 계속

AZ-104 핸즈온 : Microsoft Entra ID ID 관리 P2 - Azure RBAC(Azure role-based access control) 2

zerobig-k8s — Wed, 7 May 2025 08:04:31 +0900

1. Azure Role 할당

1.1 Custom Role 생성 및 할당

이번 핸즈 온에서는 Azure 클라우드 엔니지어 특히 MSP 관련 업무를 수행하는 담당자에게 매우 유용한 클라우드 최적화 도구인 Advisor와 관련한 Custom Role 할당을 예시로 진행해 보겠다.

구축 단계에서 고객의 요건을 완전하게 이해하고 소위 WAF(Well-Architected Framework)에 입각하여 솔루션 설계 및 구축을 했겠지만 실제 클라우드를 이용하게 되면서 비용, 성능, 보안, 안전성 및 운영효율성 등에 대한 최적화가 필요하고 이루어 지게 된다. Advisor가 바로 이런 기능을 제공해 준다.

Advisor란

Azure Advisor는 모범 사례를 따라 Azure 배포를 최적화하는 데 도움을 주는 디지털 클라우드 도우미입니다. 주요 기능은 다음과 같다:

비용 절감: Azure 사용량을 최적화하여 비용을 절감할 수 있는 기회를 제공.
성능 향상: 애플리케이션의 속도를 개선할 수 있는 권장 사항을 제시.
보안 강화: 보안 위협과 취약점을 탐지하고 해결책을 제안.
안정성 보장: 비즈니스에 중요한 애플리케이션의 연속성을 보장.
운영 효율성: 프로세스와 워크플로의 효율성을 높이는 권장 사항을 제공

Azure 포털에서 Advisor를 통해 개인화된 권장 사항을 확인하고, 이를 통해 Azure 리소스를 최적화할 수 있다.

Advisor에 대한 자세한 내용은 여기를 참조한다.

참고로 Azure Advisor 관련 역할에 대한 요약 정보는 다음과 같다.

이제 Custom Role을 생성해보자.

1) Azure 구독 Access control (IAM) 블레이드에서 + Add의 Add custom role을 선택한다.

2) Basics 탭에서 생성할 Role의 이름, 설명을 입력하고 Baseline permissions는 Start from scratch를 선택하여 처음부터 만들어 나가자.

3) Permissions 탭에서 Add permissions를 선택한다.

검색 창에 “Advisor”를 입력하여 결과 중 Microsoft Advisor를 선택한다.

Microsoft.Advisor/generateRecommendations 퍼미션 중 Read : Get generate recommendations status를 체크하고 Add 한다.

이제 생성된 Custom Role을 할당해보자.

4) Azure 구독 Access control (IAM) 블레이드에서 + Add의 Add role assignment를 선택 후 “Advisor” 라고 입력 후 생성한 역할을 검색 및 선택하고 Next를 클릭한다.

Members 탭에서 +Select members를 선택 후 해당 역할을 할당할 사용자를 검색, 선택 후 Select를 선택하고 Next를 클릭한다.

Assignment type 탭에서 Assignment type으로 Active를 선택 후 Review + assign울 클릭하여 역할을 할당한다.

역할 할당이 잘 되었다면, Role assignments 탭에서 다음과 같은 결과를 확인할 수 있다.

참고로 생성한 Custom Role은 관리 용이성 및 보안 등의 사유로 그룹에 할당하는 것이 보다 모범사례 이지만 이 실습에서는 간소화를 위해 사용자에게 역할을 할당하도록 한다.

1.2 Custom Role 할당 결과 검증

먼저 Custom Role을 할당 받은 사용자로 로그인하여 Advisor를 확인하기에 앞서 현재 사용자를 통해 Advisor를 검색하여 확인해 보자. 참고로 현재 사용자는 Owner 역할을 할당 받은 상태이며, 그렇지 않다면, Owner 역할을 할당 받은 사용자로 로그인 한다.

포털 상단 검색창에 advisor라고 입력한 후 결과 서비스 중 Advisror를 선택한다.

다음과 같이, Cost, Security, Reliability, Operational 및 Performance 등 5개의 범주에 대한 권장사항(recommendations) 및 보안 점수(Score) 정보에 대한 개요 페이지를 전시해준다.

각 범주를 선택해서 들어가면 해당 범주 관련 권고사항 리스트를 전시해준다.

임의의 권고사항을 선택하여 이동하면 각 범주 별로 관련한 권장 조치(Recommended actions) 및 해결 단계(Remediation steps) 정보를 제공해준다.

# 권장 조치 예시

Advisor에 대한 자세한 내용은 여기를 참조한다.

이제 위에서 Custom Role (Advisor-ReadScore)를 할당 받은 사용자로 로그인 하여 비교 검증한다.

해당 사용자는 보안점수에 대한 정보는 확인이 가능하지만, 권고사항 등에 대한 정보는 얻을 수 없음을 확인할 수 있다.

2. Azure Role vs Entra ID Role

기본적으로 Azure 역할과 Microsoft Entra ID 역할은 별개라고 하였다. Entra ID의 전역관리자Global Admin) Role을 할당 받은 두 사용자를 비교하며 검증해보도록 하겠다.

m365e54zerobig 테넌트 내 Global Admin 역할을 할당 받은 두 사용자 통해 Azure 접근 가능 여부에 대해 확인해 보도록 하겠다. 참고로 해당 테넌트에는 TDG_VSE라는 구독이 연결되어 있다.

위 사용자 중 zerobig.devops 사용자의 경우를 먼저 살펴보자.

TDG_VSE 구독의 권한 할당 현황을 살펴보면 사용자 zerobig.devops에 대하여 소유자 권한이 할당되어 있음을 확인할 수 있고, 따라서 해당 구독에 접근이 가능한 것은 당연한 결과이다.

이제 해당 테넌트 내 또 다른 Global Admin을 역할을 소유한 YDKim-NAVER 사용자의 경우를 살펴보자.

구독에 대한 접근 권한이 없을을 확인할 수 있으며, 이로서 Entra ID 역할과 Azure의 역할이 별개임을 확인할 수 있다.

Microsoft Entra ID 내 Manage > Properties 블레이드로 이동 후. Access management for Azure resources 기능을 활성화 한다.

이제 다시 구독의 접근 가능 여부를 확인한다. 이번에는 구독이 전시되는 것을 확인할 수 있다.

해당 기능 활성화 하였으므로 사용자 액세스 관리자 역할(Azure 역할)이 부여된 결과이다.

TDG_VSE 구독의 권한 할당 현황을 다시 살펴보면

해당 사용자에 대해 사용자 엑세스 관리자 역할이 할당되었음을 확인할 수 있다.

이 핸즈온을 통해 우리는 Azure Role 및 Entra ID Role에 대해 그리고 그 관계에 대해 이해할 수 있게 되었다.

다음 편에서는 Azure Policy에 대해 확인해 보도록 하겠다.

AZ-104 핸즈온 : Microsoft Entra ID ID 관리 P2 - Azure RBAC(Azure role-based access control) 1

zerobig-k8s — Fri, 28 Feb 2025 07:54:41 +0900

클라우드 리소스에 대한 액세스 관리는 클라우드에서 가장 기본이 되고 중요한 기능이다. Azure RBAC(Azure role-based access control)은 중요한 도구로서 역할 한다.

Azure RBAC는 Azure Resource Manager를 기반으로 구축된 권한 부여 시스템으로, Azure 리소스에 대한 세부적인 액세스 관리를 제공한다.

Azure RBAC는 사용자, 그룹, 애플리케이션에 대해 세분화된 접근 권한을 부여함으로써 Azure 리소스의 보안과 관리를 효율적으로 수행할 수 있도록 지원한다. 이를 통해 조직은 “최소 권한 원칙”을 준수하며, 리소스에 대한 접근을 체계적으로 제어할 수 있다. “최소 권한 원칙”은 제로 트러스트의 핵심이 되는 주요 원칙 중 하나이다.

이번 글은 Azure 및 Microsoft Entra ID 역할에 대한 이론과 그에 따른 핸즈온으로 각각 나누워 게시 하도록 하겠다.

Azure Role의 이해

1. RBAC의 기본 개념

핵심 개념을 간단하게 설명하자면 "누가(Who), 무엇을(What), 어디에서(Where) 할 수 있는가?"를 정의 해주는 것이다. 각각은 다음을 의미한다.

Who(누가): Entra ID 테넌트 내의 사용자, 그룹, 서비스 주체 등의 보안 주체.
What(무엇을): 역할 정의(Role Definition)와 역할 할당(Role Assignment)을 통해 보안 주체에게 부여된 권한.
Where(어디에서): 역할이 적용되는 범위(Scope)로, 관리 그룹, 구독, 리소스 그룹, 개별 리소스 등에서 설정 가능.

2. Azure 역할

2,1 보안 주체(Security principal)

Azure 역할을 사용하면 보안 주체(사용자, 그룹, 서비스 주체 또는 관리 ID)를 대상으로 Azure 구독 내 리소스(VM, VNET, Resource Group 등)에 대한 접근 제어를 할 수 있다.

Azure의 주요 기본 역할은 다음과 같다.

Owner(소유자): 리소스에 대한 전체 접근 권한 및 다른 사용자에게 권한 위임 가능.
Contributor(기여자): 리소스 생성 및 관리 가능,但 다른 사용자의 접근 권한은 관리 불가.
Reader(읽기 권한자): 리소스 조회만 가능, 수정 불가.
User Access Administrator(사용자 접근 관리자): 사용자 접근 권한 관리 가능, 리소스 자체는 관리 불가.

2.2 역할 정의

역할 정의는 권한의 모음을 말하며 일반적으로 역할이라 칭한다. 역할 정의에는 읽기, 쓰기, 삭제 등 수행할 수 있는 작업이 나열된다. 역할은 소유자와 같은 상위 수준일 수도 있고 가상 머신 리더와 같은 특정 수준일 수도 있다.

Azure에는 가상 머신 기여자 등과 같이 바로 사용할 수 있는 기본 제공 역할이 포함되어 있다. 더불어 조직의 특정 요구 사항을 충족하지 않는 경우 고유한 Azure 사용자 지정 역할을 만들 수 있다.

2.3 범위(Scope)

범위는 액세스가 적용되는 리소스 집합이다. 역할 할당은 계층적 구조(예: 관리 그룹 → 구독 → 리소스 그룹 → 리소스)에서 상속되며, 상위 범위에서 할당된 역할은 하위 범위까지 적용된다. 범위는 부모-자식 관계로 구조화됩니다. 이러한 범위의 모든 수준에서 역할을 할당할 수 있다.

2.4 역할 할당

역할 할당이란 특정 범위를 대상으로 사용자, 그룹, 서비스 주체 또는 관리 ID에 역할 정의를 첨부해주는 프로세스를 말한다.

3. Entra ID 역할

Entra ID 테넌트 자체 내에서 관리되는 ID 개체에 대한 액세스를 제공하기 위한 특수한 역할 집합을 의미한다. 이 역할은 Azure 리소스가 존재하는 Azure 구독이 아닌, 사용자나 애플리케이션 또는 디바이스와 같은 Entra ID 리소스에 대해 특정 작업을 수행할 수 있도록 역할을 할당할 수 있다.

주요 역할은 다음과 같다.

Global Administrator(전역 관리자): Entra ID 테넌트 전체를 관리할 수 있는 최상위 권한.
User Administrator(사용자 관리자): 사용자 및 그룹 관리 권한.
Billing Administrator(청구 관리자): 빌링 관련 작업 수행 권한.
Helpdesk Administrator(헬프데스크 관리자): 사용자 비밀번호 재설정 등 헬프데스크 기능 수행 권한.

일반적으로 역할은 Scope은 테넌트 전체에 적용되지만, 관리 단위(Administrative Unit)를 통해 세부적인 범위의 특정 그룹에만 적용이 가능하다.

Entra ID 관리 단위(Administrative units)

Entra ID 테넌트 내에서 사용자, 그룹, 디바이스 등의 ID 리소스를 논리적으로 분리하고 관리할 수 있는 컨테이너이다. 대규모 조직에서 ID 리소스를 논리적으로 분리하고, 관리 권한을 세분화하여 보안과 관리 효율성을 높이는 데 유용한 기능이다. 이를 통해 조직은 부서, 지역, 프로젝트별로 관리 책임을 분산하고, 과도한 권한 부여로 인한 보안 위험을 줄일 수 있다.
보다 자세한 내용은 여기를 참조한다.

Entra ID 역시 기본 제공 역할 외에 커스텀 역할 생성이 가능하다.

4. Azure 역할 vs Entra ID 역할 비교

Azure 역할:
- 대상: Azure 구독 내 리소스(VM, VNET 등).
- 범위: 관리 그룹, 구독, 리소스 그룹, 개별 리소스.
- 주요 역할: Owner, Contributor, Reader, User Access Administrator.
Entra ID 역할:
- 대상: Entra ID 테넌트 내 ID 리소스(사용자, 애플리케이션, 디바이스 등).
- 범위: 일반적으로 테넌트 전체, 단, 관리 단위로 세부 범위 설정 가능.
- 주요 역할: Global Administrator, User Administrator, Billing Administrator, Helpdesk Administrator.

기본적으로 Azure 역할과 Microsoft Entra 역할은 별개이다.

그러나 전역 관리자가 Azure Portal에서 Azure 리소스에 대한 액세스 관리 기능을 활성화 하여 액세스 권한을 높이면 특정 테넌트의 모든 구독에 대한 사용자 액세스 관리자 역할(Azure 역할)이 부여된다. 이 역할을 통해 다른 사용자에게 Azure 리소스에 대한 액세스 권한을 부여할 수 있게 해준다. 다음 핸즈온 세션에서 해당 시나리오를 구현해 보도록 하겠다.

다음 편에서 계속

AZ-104 핸즈온 : Microsoft Entra ID ID 관리 P1 - Entra ID와 Azure 구독 3

zerobig-k8s — Tue, 31 Dec 2024 08:20:36 +0900

이전 편에서 하나의 구독을 새로운 테넌트 즉, Entra ID로 이동시키고 테넌트에서 새로운 사용자를 생성하는 내용을 다루었다. 이번 편에서는 그룹을 추가하여 라이선스를 할당 하는 등의 실습을 진행하도록 하겠다.

1.3 그룹 생성

이제 그룹을 생성하도록 하겠다.

1. Entra ID에서 Groups > New Group 을 클릭한다.

2. 다음과 같이 값을 선택 및 입력 한다.

참고로 지원되는 그룹의 유형에는 다음 2가지가 존재한다.

구분	보안 그룹 (Security Group)	Microsoft 365 그룹 (M365 Ggroup)
주요 기능	보안 및 권한 제어 공유 리소스에 대한 사용자 및 컴퓨터 액세스를 관리하는 데 사용	협업 및 생산성 도구 통합 그룹 멤버에게 공유 사서함, 일정, 파일, SharePoint 사이트 등에 대한 액세스 권한을 부여하여 협업 기회를 제공
리소스 제공 여부	리소스 직접 공유 기능 없음	공유 이메일, 파일, 캘린더, 팀 사이트 자동 제공
협업 중심 여부	협업 목적이 아닌 보안 관리 중심	팀 기반 협업 중심
외부 사용자 지원	제한적	Guest 사용자 초대 및 협업 가능

또한 지원되는 멤버의 유형에는 다음 3가지가 존재한다.

동적 멤버 자격 그룹을 사용하려면 Microsoft Entra ID P1 라이선스 또는 Intune for Education 라이선스가 필요하다.

구분	Assigned	Dynamic User	Dinamic Device
멤버 추가 방법	사용자를 수동으로 추가	사용자 속성에 따른 조건 기반 규칙 적용	디바이스 속성에 따른 조건 기반 규칙 적용
사용 사례	관리자가 직접 그룹 멤버를 지정하여 고정된 구성원을 관리해야 하는 경우. 예: 특정 프로젝트 팀 구성원, VIP 사용자 그룹.	사용자의 속성(예: 부서 = "IT", 직무 = "Manager")에 따라 자동으로 그룹에 추가되거나 제거되는 경우. 예: 특정 부서에 소속된 사용자만 접근해야 하는 애플리케이션 그룹.	디바이스 속성(예: OS = "Windows 11", Intune 등록 상태 = "True")에 따라 디바이스를 그룹화하는 경우. 예: Windows 11 디바이스에만 적용할 Intune 정책 그룹.

3. create를 클릭하여 그룹을 생성한다.

4. Groups > All groups로 이동하면 새로 생성한 그룹이 전시되는 것을 확인할 수 있다.

5. 생성된 그룹을 선택하고 Manage > Members > +Add memebers를 클릭한다.

6. Users 탭에서 다음 2 사용자를 선택하여 멤버로 추가한다.

7. 추가한 멤버 2명이 추가된 화면을 볼 수 있다.

1.4 동적 그룹 생성 및 테스트

이번 동적 그룹 핸즈온을 수행하기 위해서는 Entra ID P1 라이선스 이상이 필요하다.

1. CloudEng_Group의 Properties로 이동하여 Membership type을 Dynamic User로 선택 후 Add dynamic query를 클릭한다.

2. 다음과 같은 내용으로 선택 및 입력하고 Save 한다.

Properties	Operator	Value
jobTitle	Equals	Cloud Engineer

3. 이제 위에서 수행했던 사용자 추가 절차를 참고하여 새로운 사용자를 추가한다. 이때 Properties의 Job title 값을 Cloud Engineer로 입력한다. 이후 라이선스 할당 실습에서 이 속성 값을 가지는 사용자에 대하여 라이선스 할당이 이루어 질 예정이다.

4. 위에서 수행했던 사용자 추가 절차를 참고하여 새로운 사용자를 추가한다. 이때 Properties의 Job title 값을 Cloud Engineer로 입력한다.

5. 이제 GloudEng_Group의 Mmebers 페이지로 이동하여 멤버 정보를 확인해본다. 다음과 같이 3명의 사용자가 추가되어 있음을 확인할 수 있다.

2. 라이선스 할당 테스트

2.1 라이선스 보유 현황 확인

1. Entra ID의 Manage > Licenses 페이지로 이동한다.

2. Manage > All products 페이지로 이동하면 보유한 제품 현황 및 각 라이선스 정보에 대한 현황을 확인할 수 있다.

이 중 개 있으며 23개가 가용한 상태이다.

1.2 Entra ID 역할 부여

현재 라이선스 할당 추가, 제거 등은 M365 관리 센터에서만 가능한 상태이고 로그인을 하기 위해서는 Entra ID 역할 부여가 필요하므로 먼저 위에서 생성한 사용자 azure-mvp@thezerobig.com 에 대해 Global Admin 권한을 부여한다.

1. Entra ID의 Users 리스트에서 azure-mvp@thezerobig.com를 선택한 후 Assigned roles 블레이드로 이동한다.

2. + Add assignments를 선택한다.

3. Select role에서 Global Administrator를 선택하고 Next를 선택한다.

4. Assignment type을 Active로 하고 Enter justification에 Active로 설정하는 근거에 대한 설명 등을 입력 후 Assign을 클릭한다.

경고
Eligible 역할 할당은 사용자가 역할을 활성화(Active)하기 위해 하나 이상의 작업을 수행해야 함을 의미한다. Active 역할 할당은 사용자에게 즉시 역할을 활성화 하려는 경우에 사용한다.
실무에서는 최소 권한 원칙 관행을 따르고 보안 리스크를 최소화 하는 방식으로 진행하는 것을 권장하며 사용자의 Microsoft Entra 역할 할당과 관련한 보다 자세한 내용은 여기를 참조한다..

5. 잠시 후 역할이 부여 된 것을 확인하고 M365 Admin Center로 이동하여 로그인을 수행한다.

2.2 라이선스 할당 테스트

라이선스는 사용자 또는 그룹을 대상으로 할당할 수 있다. 여기서는 그룹을 대상으로 할당하는 시나리오를 기준으로 진행한다.

1. 라이선스 페이지 구독 탭 리스트에서 할당하려는 라이선스를 선택한다. 여기서는 Microsoft 365 E5 개발자(Windows 및 오디오 회의 제외)를 기준으로 진행한다.

2. 그룹 탭을 선택하고 + 라이선스 할당을 선택한다.

3. CloudEng_Group그룹을 검색하여 선택하고 할당을 클릭한다.

할당에 대한 확인창이 전시되며 X를 눌러 창을 닫는다.

4. 이제 그룹에 속한 사용자의 계정에 대해 라이선스 할당 여부를 검증한다.

먼저 demouser01@thezerobig.com 계정으로 https://myapplications.microsoft.com에 로그인 하여 결과를 확인한다.

m365e54zerobig 테넌트 내 demouser01@thezerobig.com 사용자에게 할당된 M365 라이선스로부터 사용 가능한 앱 리스트가 전시되는 것을 확인할 수 있다.

이 중 Teams를 선택하여 로그인 해보면 정상적으로 사용이 가능함을 알 수 있다.

다음 zer0big@naver.com 계정으로 https://myapplications.microsoft.com에 로그인 하여 결과를 확인한다.

최초 로그인 시도 시 앱 대시보드 화면이 비워 있는 것과는 달리 역시 M365 관련 앱들이 전시된다.

Guest 사용자에 대한 라이선스 할당 이슈
이 글을 작성하기 위해 테스트를 반복하는 과정에서 외부 게스트 사용자에 대한 (여기서는 zer0big@naver.com) 라이선스 할당이 정상적으로 이루어 지지 않는 현상을 체험했다. (이 부분에 대한 확인을 위해 상당 시간이 소요 되었다.) 공식적으로는 할당이 불가하다는 내용을 확인했다. 이와 관련해서는 여기를 참조한다.

다음 편에서는 Azure의 Role과 Access Control에 대한 핸즈온을 시행해 보도록 하겠다.

AZ-104 핸즈온 : Microsoft Entra ID ID 관리 P1 - Entra ID와 Azure 구독 2

zerobig-k8s — Fri, 20 Dec 2024 08:17:32 +0900

이번 편에서는 하나의 구독을 새로운 테넌트 즉, Entra ID로 이동시키고 테넌트에서 새로운 사용자 및 그룹을 추가하여 라이선스를 할당 하는 등의 실습을 진행하도록 하겠다. 핸즈온 내용이 다소 방대해서 2편으로 나누어 정리 및 게시하도록 하겠다.

조직에는 여러 Azure 구독이 있을 수 있다. 각 구독은 특정 Microsoft Entra 디렉터리와 연결된다. 관리의 용이성 등의 목적으로 임의의 구독을 다른 Microsoft Entra 디렉터리로 이동시킬 수 있다. 이 때 Azure RBAC의 모든 역할 할당들은 대상 디렉터리로 전송되지 않고 영구적으로 유실되므로 사전에 신중하게 계획하고 실행해야 한다. 이와 관련한 상세한 내용은 여기를 참조한다.

핸즈온 1 : Azure 구독 Microsoft 디렉토리 연결

목표

소스 디렉토리(ssprdemo)에 연결된 TDG_VSE 구독을 타겟 디렉토리(thezerobig.com)으로 이동(연결) 시킨다.

사전 요구 사항

Azure 구독에 대한 소유자 역할이 있는 계정
Microsoft Entra ID 디렉토리를 생성할 권한이 있는 계정

-------------------------------------------------------------------------------------------------------------------------------------------------

핸즈온 단계

1. 소스 디렉토리 작업

1.1 Azure Portal 로그인 및 디렉토리 변경

Azure Portal에 로그인하고 상단에 → Change directory를 선택한다.

정상적으로 변경이 된 경우, 디렉토리 변경에 대한 알림이 팝업된다. 실제 대상 디렉토리에 해당 구독이 전시되는데 약 10분 정도 소요될 수 있음을 안내한다.

2. 타겟 디렉토리 작업

타겟 디렉토리로 이동하여 구독 리스트를 확인한다.

TDG_VSE 구독의 Overview 블레이드에서 디렉토리 정보를 확인한다. 기존 ssprdemo에서 thezerobig.com 디렉토리로 변경된 것을 확인할 수 있다.

참고:
이후 세션에서 시행할 라이선스 할당 핸즈온 등의 환경 준비를 위해 기존 핸즈온을 통해 수행한 Azure 구독(TDG_VSE)을 최종적으로 새로운 디렉토리에 m365e54zerobig(1560ed56…) 연결하고 이 디렉토리에서 thezerobig.com 으로 커스텀 도메인 후 기본 디렉토리로 적용했다. 필자의 경우, 이 새로운 디렉토리 즉, 테넌트에
Microsoft 365 E5 Developer (without Windows and Audio Conferencing) 가 총 25개 존재하게 때문이다.

핸즈온 2 : 테넌트 내 사용자 및 그룹 생성과 라이선스 할당

목표

Microsoft Entra ID에서 사용자와 그룹 생성.
사용자 및 그룹에 Microsoft 365 라이선스 할당.

M365 라이선스 할당에 대한 내용은 AZ-104에서 다루는 영역은 아니다. Azure와 Microsoft 365(M365)의 테넌트는 각기 다른 목적과 역할을 가지고 있지만 실무적으로 서로 분리하여 생각할 수 없는 긴밀성과 연결고리가 존재한다. Azure와 M365가 하나의 Entra ID 테넌트를 공유함으로써 조직은 ID 및 액세스 관리를 중앙에서 효율적으로 수행할 수 있으며, 보안과 사용자 경험을 모두 향상시킬 수 있다. 이번 핸즈온에서는 테넌트 내 생성된 사용자를 대상으로 M365 라이선스를 할당하고 Azure의 역할을 할당하는 정도의 시나리오만 다룰 예정이다.

핸즈온 단계

1. 사용자 및 그룹 생성

1.1 새 사용자 생성 (내부 멤버)

Microsoft Entra ID에서 사용자 유형은 간략하게 다음과 같으며 자세한 내용은 여기를 참조한다.
- 내부 멤버: 조직(테넌트)의 정규직원일 가능성이 높다.
- 내부 게스트: 테넌트 내 계정을 가지고 있지만 게스트 수준 권한을 갖는다. B2B 협업을 사용할 수 있게 되기 전에 테넌트 내에서 생성되었을 수 있다.
- 외부 멤버: 외부 계정을 사용하여 인증하지만 테넌트에서 구성원에 액세스할 수 있다. 이러한 형식의 사용자는 다중 테넌트 조직에서 일반적이다.
- 외부 게스트: 외부의 방식을 사용해 인증하고 게스트 수준 권한을 가진 테넌트 내의 진정한 게스트이다.

1. Entra ID에서 Users > + New user > Create new user를 클릭한다.

2. Basics 탭에서 user principal name, Display name 등을 입력하고 Next Properties를 클릭한다.

3. Properties 탭에서 기본적인 속성 정보를 입력하고 Review + create를 클릭 하고 다시 create를 클릭하여 사용자를 생성한다. 여기서 Job title 속성 값이 Cloud Engineer 인 점을 주목한다. 후에 해당 값을 조건으로 해서 라이선스 할당 테스트를 시행할 예정이다.

4. Users 블레이드에서 Refresh를 클릭하면 새로 생성된 사용자가 전시되는 것을 확인할 수 있다.

1.2 외부 게스트 사용자 생성

1. Entra ID에서 Users > + New user > Invite external user를 클릭한다.

2. Basics 탭에서 Email, Display name 및 초대 메시지 등을 입력하고 Next Properties를 클릭한다.

4. 이제 NAVER 메일 수신함에 초대 메일이 수신됨을 확인할 수 있다. Accept invitation을 클릭하여 초대 수락 과정을 진행한다.

5. 권한 요청 창에서 동의함을 클릭한다.

6. 동의가 이루어지면, 해당 계정에 대한 앱 대시보드 화면이 전시된다.

이후 라이선스 할당 테스트 단계에서 위 대시보드에 할당된 라이선스들이 전시될 것이다.

다음 편에서 계속

AZ-104 핸즈온 : Microsoft Entra ID ID 관리 P1 - Entra ID와 Azure 구독 1

zerobig-k8s — Mon, 2 Dec 2024 07:51:45 +0900

Azure 클라우드 내부에서 최소의 단위는 Resource이며 가상 머신, 스토리지 계정, 가상 네트워크 등등을 의미한다. 이러한 리소스들을 Resource Group 이라는 논리적 컨테이너로 묶어 관리할 수 있다. 함께 수명주기를 공유하고, 모니터링, 액세스 제어 및 배포 설정 등을 할 수 있다. 또한 리소스 그룹을 사용하여 리소스를 기능, 프로젝트 또는 애플리케이션 별로 논리적으로 구성할 수 있다.

Azure 구독은 실제 리소스의 경계이며, 리소스 그룹과 리소스 그룹에 포함된 모든 관련 리소스를 함께 그룹화하는 논리적 구조이다. 구독은 Azure Cloud 비용을 결정하기 위한 청구 단위로 사용된다.

Azure 구독은 항상 하나의 Microsoft Entra 테넌트에만 연결할 수 있다. Azure 구독을 활성화 하면 기본적으로 하나의 고유 테넌트에 연결이 된 상태가 된다. 이 연결을 통해 특정 Microsoft Entra 테넌트에 존재하는 사용자, 그룹 및 애플리케이션에 Azure 구독의 리소스에 대한 권한을 (RBAC를 통해) 부여할 수 있다.

여기서 테넌트라는 용어는 일반적으로 Microsoft 365, Intune 또는 Azure와 같은 Microsoft 클라우드 기반 서비스 구독에 등록한 회사 또는 조직을 나타내며, 각 서비스는 Microsoft Entra ID를 사용한다. 하지만 기술적인 관점에서 테넌트라는 용어는 개별 Microsoft Entra 인스턴스를 나타낸다.

Azure 구독 내에서 여러 Microsoft Entra 테넌트를 만들 수 있다. 다른 테넌트에 영향을 주지 않고 한 테넌트에서 Microsoft Entra 기능을 테스트하려는 경우 여러 개의 Microsoft Entra 테넌트를 보유하는 것이 편리할 수 있다.

GhatGPT에게 Entra ID와 Azure 구독에 대한 관계를 설명해달라고 해 봤다. 결과는 다음과 같다.

Entra ID와 Azure 구독의 관계

Microsoft Entra ID는 Azure 리소스에 대한 인증 및 권한 부여를 담당하는 Identity as a Service (IDaaS) 플랫폼입니니다.

Entra ID 역할: 사용자의 인증과 액세스를 관리하며 Azure 구독에 할당된 리소스의 보안을 강화합니다.

Azure 구독: 리소스 사용과 청구 관리를 위한 Azure의 기본 단위입니다. Entra ID는 Azure 구독의 ID 공급자로 작동합니다.

주요 연결점:

Entra ID에 등록된 사용자 및 그룹은 Azure 구독의 리소스에 대해 권한을 할당 받을 수 있습니다.

역할 기반 액세스 제어 (RBAC)를 통해 Entra ID 사용자와 그룹은 Azure 구독 및 리소스에 접근 권한을 부여 받습니다.

각 Azure 구독은 Entra ID 테넌트와 연결됩니다.

이제 이 개념을 토대로 핸즈온을 해보록 하자.

핸즈온: Entra ID와 Azure 구독 관계 실습

목표

Entra ID 테넌트를 이해하고 Azure 구독에 사용자 및 그룹을 할당하여 권한을 테스트한다.

사전 요구 사항

Azure 구독
Entra ID 관리자 권한

-------------------------------------------------------------------------------------------------------------------------------------------------

핸즈온 단계

1. Entra ID 테넌트 확인

1.1 Azure Portal 로그인

Azure Portal에 로그인한다.

1.2 테넌트 정보 확인

상단 검색창에서 Entra ID를 입력하고 선택한다.

Overveiw 탭에서 현재 테넌트 이름과 ID, 기본 도메인 및 라이선스 정보를 확인할 수 있다.

가 Microsoft Entra 테넌트에는 domainname.onmicrosoft.com과 같은 초기 도메인 이름이 제공된다. 이 초기 도메인 이름은 변경하거나 삭제할 수는 없다. 이 도메인에 하나 이상의 사용자 지정 도메인 이름을 추가하여 대신 사용할 수 있으며 이것이 실무에서는 일반적이며 실제로 필자 소유의 thezerobig.com 도메인을 추가하여 기본 도메인으로 사용해 보도록 하자.

-------------------------------------------------------------------------------------------------------------------------------------------------

2. 사용자 지정 도메인 추가하기

2.1 사용자 지정 도메인 이름 추가

1. Manage > Custom domain names로 이동하여 + Add custom domain을 선택한다.

2. Custom domain name 입력 창에 소유한 도메인을 입력한다.

3. 도메인 소유권의 유효성을 검사하는 화면이 전시되며, 유효성 검사에 필요한 DNS 정보를 보여 주는데 이 정보를 저장한다.

2.2 도메인 등록 기간에 DNS 정보 추가

1. 소유한 해당 도메인 등록 기관으로 이동하여 이전 단계에서 복사한 TXT 파일에서 DNS 정보를 추가해야 한다.

2. 먼저 각 자 소유한 도메인 관리 화면으로 이동한다. 필자는 Azure Portal의 App Service Domains를 통해 도메인을 구매했으므로 Azure Portal의 App Service Domains 화면으로 이동했다. Azure Portal의 App Service Domains의 구매 및 앱 구성에 대한 정보는 여기를 참고한다.

App Service Domains > Overview 블레이드에서 Manage DNS records를 클릭한다.

3. Record sets를 선택한다.

4. + Add를 클릭하고 다음과 같이 복사한 정보를 토대로 레코드 셋을 입력 및 선택한다.

5. 다시 Manage > Custom domain names 화면으로 돌아와 Verify를 클릭하여 유효성을 검증한다.

위에서 추가한 레코드가 전파되는 중이므로 도메인 유효성 확인이 완료되는 데 1시간 이상이 소요될 수 있다.

참고
필자와 달리 다른 Azure 포털이 아닌 다른 호스팅 업체에서 도메인을 구입한 경우에도 유사한 방식으로 레코드 추가 화면에서 위 과정을 수행하면 된다.
아래 예시는 호스팅 KR을 통해 필자가 추가로 구매하여 보유한 zerobig.kr 도메인에 대한 레코드 추가 관리 화면 이다.

6. 새로운 창에서 Manage > Custom domain names 화면으로 이동하여 결과를 확인해 보면 정상적으로 Verified 가 이우러 진 것을 확인할 수 있다. 필자의 경우에는 약 10분 정도 소요되었다.

3. 사용자 지정 도메인을 기본 도메인으로 지정하기

이제 정상적으로 사용자 지정 도메인이 추가 되었으니 이 도메인을 Entra ID의 기본 도메인으로 설정하여 사용하고자 한다.

1. 먼저 추가된 사용자 지정 도메인으로 들어가 Make primary를 클릭한다.

2. Entra ID의 Overview 블레이드로 이동하여 Primary domain의 값을 확인해 본다. 이제 추가한 사용자 지정 도메인이 기본 도메인으로 지정되었음을 확인할 수 있다. 화면에 정상적으로 업데이트 된 값이 전시 되기 전까지 수분이 소요될 수 있다.

이제 다음 편에서는 생성한 테넌트에서 새로운 사용자 및 그룹 추가, 라이선스 할당, 테넌트와 구독 연결 등의 내용으로 실습을 진행하도록 하자.

다음 편에서 계속

AZ-104 핸즈온 시리즈 따라하기 : 소개

zerobig-k8s — Mon, 11 Nov 2024 08:20:47 +0900

이번 시리즈에서는 Azure 클라우드를 처음 실무로 접하게 되는 대상자(관리, 구축 및 설계자)를 위해 준비하게 되었다.

물론 어느 정도 Azure 클라우드를 알고 있지만(가량 이미 자격을 취득한 사람들) 핸즈온 위주로 따라하며 다시 기초를 다지고자 하는 사람들에게도 유용한 시리즈가 될 것으로 여겨진다. 참고로 이 글의 목적은 AZ-104 자격증 취득이 아니라 실질적인 핸즈온 기술역량 강화에 그 목적이 있다.

실무에서 Azure 클라우드에 새로 온보딩하는 SA(Soulutions Architect)나 DevOps Engineer에게 기본적으로 요구되는 기술역량이 있는데, 바로 AZ-104가 주로 다루는 내용들이 바로 그것이다.

필자는 수시로 회사에서 신규입사자 또는 고객들을 대상으로 Azure에 대한 기본 역량 강화를 구상하고 시행하고 있다.

이를 목적으로 이론 보다는 주로 핸즈온 위주 따라하기 컨텐츠를 준비하게 되었다. 물론 기본 적인 개념을 함께 다루겠지만 보다 탄탄한 기술 역량을 갖추기 위해서 각자 별도의 시간을 할애하여 MS Learn 등의 학습 컨텐츠를 통해 따로 공부해 나가야 할 것이다.

이제 실제 필자와 함께 각자의 구독환경에서 이 시리즈를 따라하다 보면, 어느 새 Azure에 대한 전반적인 이해도 및 특히 핸즈온 역량이 강화되리라고 믿는다.

이제부터 우리는 다음의 내용들을 가지고 핸즈온 위주의 랩을 실행해 나갈 것이다.

AZ-104: Azure 내 ID 및 거버넌스 관리
AZ-104: Azure 내 스토리지 구현 및 관리
AZ-104: Azure 컴퓨팅 리소스 배포 및 관리
AZ-104: Azure 관리자를 위한 가상 네트워크 구성 및 관리
AZ-104: Azure 리소스 모니터링 및 백업

다음 편에서는 "AZ-104: Azure 내 ID 및 거버넌스 관리"를 시작으로 본 시리즈를 시작해 보겠다.

Azure DevOps를 활용한 Git 기초 및 활용 Part 2

zerobig-k8s — Thu, 29 Aug 2024 08:20:49 +0900

5. Branch 전략 수립하기

터미널 상에서 다음 명령을 수행하여 현재 브랜치 현황을 확인해 본다.

git branch -a

ADO-git-handson# git branch -a
* master
  remotes/origin/master
ADO-git-handson#

현재 master 브랜치에서 작업이 이루어 지고 있으며 로컬, 리모트 모두 하나의 브랜치만 존재함을 알 수 있다.

이 구조는 Git을 처음으로 접하여 이런 저런 명령을 수행하거나, 단순한 개인 실습을 수행하는데 별 문제 없지만 실무에서의 현실에서는 master 브랜치를 단일로 유지 및 관리하는 것은 바람직 하지 않다.

실무 협업 환경에서는 소위 Git 브랜치 전략을 채택하여 보다 보안적으로 안전하게 버전 제어를 사용하여 코드를 공유하고 관리 하는 관행이 필요하다.

Git 브랜치 전략 채택

현재 master 브랜치 내의 코드는 인증 정보만 있으면 누구나 바로 복제 및 코드 변경이 가능한 상태이므로 이에 대한 보완이 필요하다. 소위 “Git 브랜치 전략”업데이트 할 수 있는 보안적으로 취약한 상태이다.

다시 터미널에서 README.md 파일을 열고 임의의 메시지를 추가 입력한다. 참고로 필자의 경우에는 # Now we can modify this file directly on the master brancch :( 라고 입력했다. 그리고 나서 git status 명령을 수행한다.

vi README.md
cat README.md
git status

ADO-git-handson# vi README.md
ADO-git-handson# cat README.md
Hello~ GIT~:)
# Now we can modify this file directly on the master brancch :(
ADO-git-handson#
ADO-git-handson# git status
On branch master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   README.md

no changes added to commit (use "git add" and/or "git commit -a")
ADO-git-handson#

이제 다시 다음과 같이 git add, commit 및 push 명령을 수행하여 리모트 브랜치로 병합한다.

git add .
git commit -m "Add a README.md"
git push

ADO-git-handson# git add .
ADO-git-handson# git commit -m "Modify README.md adding the comment"
[master 85354b7] Modify README.md adding the comment
 1 file changed, 1 insertion(+)
ADO-git-handson# git push
Password for 'https://zerobig-devops4demo@dev.azure.com':
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 12 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 342 bytes | 6.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: Analyzing objects... (3/3) (7 ms)
remote: Validating commits... (1/1) done (0 ms)
remote: Storing packfile... done (29 ms)
remote: Storing index... done (49 ms)
To https://dev.azure.com/zerobig-devops4demo/20240809_AzureDevOps_Git_Demo/_git/20240815_AzureDevOps_Git_Demo
   c986055..85354b7  master -> master
ADO-git-handson#

이제 웹 브라우저로 이동하고 Remote 리포지토리를 새로고침하여 푸시 결과를 확인한다.

수정된 내용이 반영되어 있음을 확인할 수 있다.

Git은 버전 제어를 사용하여 코드를 공유하고 관리하는 방법을 유연하게 제공하며 팀은 이러한 유연성과 일관된 방식으로 코드를 공동 작업하고 공유해야 하는 필요성 사이의 균형을 찾아야 한다.

팀 구성원은 다른 팀원과 공유되는 Git 브랜치를 통해 코드 변경 사항항을 게시, 공유, 검토 및 반복하는 작업을 수행한다. 이러한 팀을 위한 브랜치 전략을 채택한다. 더 효율적으로 협업하고 버전 제어에 대한 관리 시간을 줄이고 코드를 개발하는 데 더 많은 시간을 할애할 수 있도록 한다.

다음 브랜치 전략은 Microsoft에서 Git을 사용하는 방법을 기반으로 하며 자세한 내용은 Microsoft에서 Git을 사용하는 방법을 참조한다.

브랜치 전략을 단순하게 유지한다. 다음 세 가지 개념으로 전략을 빌드한다.

새로운 모든 기능과 버그 수정에 feature 브랜치를 사용한다.
Pull Request를 사용하여 feature 브랜치를 master 브랜치에 병합한다.
고품질의 최신 master 브랜치를 유지한다.

이러한 개념을 확장하고 모순을 피하는 전략을 통해 팀은 일관되고 따르기 쉬운 버전 제어 워크플로를 얻을 수 있다.

Git 브랜치 전략 구성

이제 master 브랜치를 보호할 수 있도록 구성을 해보겠다.

Azure Repo > Branches로 이동하여 master 브랜치를 선택하고 추가 옵션에서 branch policies를 선택한다.

Branch Policies - Require a minimum number of reviewers를 “1”로 설정하고 데모의 편의성을을 위해 Allow requestors to approve their own changes를 체크한다.

현재 시나리오에서는 간단히 하기 위해서 “Allow requestors to approve their own changes
”를 활성화하여 본인이 직접 Pull Request를 요청하고 검토 후 처리하지만 실무에서는 1명 이상의 다른 검토자를 지정하고 코드 검토 및 승인할 수 있도록 하는 관행이 필요하다.

이제 다시 터미널에서 README.md 파일을 열고 메시지 내의 오타를 수정한다. “brancch:에서 “c”를 하나 제거하여 저장한다.

vi README.md
README.md

ADO-git-handson# vi README.md
ADO-git-handson# cat README.md
Hello~ GIT~:)
# Now we can modify this file directly on the master branch :(
ADO-git-handson#

이제 다시 다음 명령을 수행하여 리모트 브랜치로 병합한다.

git commit -am "Modify README.md correcting the typeo in the comment"
git push

ADO-git-handson# git commit -am "Modify README.md correcting the typeo in the comment"
[master 437b06c] Modify README.md correcting the typeo in the comment
 1 file changed, 1 insertion(+), 1 deletion(-)
ADO-git-handson# git push
Password for 'https://zerobig-devops4demo@dev.azure.com':
ADO-git-handson# git push
Password for 'https://zerobig-devops4demo@dev.azure.com':
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 12 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 302 bytes | 7.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: Analyzing objects... (3/3) (32 ms)
remote: Validating commits... (1/1) done (0 ms)
remote: Storing packfile... done (29 ms)
remote: Storing index... done (31 ms)
To https://dev.azure.com/zerobig-devops4demo/20240809_AzureDevOps_Git_Demo/_git/20240815_AzureDevOps_Git_Demo
 ! [remote rejected] master -> master (TF402455: Pushes to this branch are not permitted; you must use a pull request to update this branch.)
error: failed to push some refs to 'https://zerobig-devops4demo@dev.azure.com/zerobig-devops4demo/20240809_AzureDevOps_Git_Demo/_git/20240815_AzureDevOps_Git_Demo'
ADO-git-handson#

“To https://dev.azure.com/zerobig-devops4demo/20240809_AzureDevOps_Git_Demo/_git/20240815_AzureDevOps_Git_Demo
! [remote rejected] master -> master (TF402455: Pushes to this branch are not permitted; you must use a pull request to update this branch.)
error: failed to push some refs to 'https://zerobig-devops4demo@dev.azure.com/zerobig-devops4demo/20240809_AzureDevOps_Git_Demo/_git/20240815_AzureDevOps_Git_Demo'” 에러가 발생함을 확인할 수 있다. 즉, 이 브랜치에 대한 푸시는 허용되지 않았으며 이 브랜치의 업데이트는 Pull Request를 통해서만 가능함을 알 수 있다.

이제 새로운 브랜치에서의 코드 변경 및 Pull Request 수행을 master 브랜치로의 병합을 시도해 보겠다.

6. 새로운 브랜치 생성하여 작업하기

다음 명령을 수행하여 새로운 브랜치 “feature”를 생성한다.

git checkout -b feature
git branch
git log --oneline --graph

생성한 feature 브랜치의 로그를 조회해보면 master 브랜치와 동일한 커밋 이력을 가지고 있으며, 동일한 커밋에 HEAD가 포인팅 되어 있음을 확인할 수 있다. 따라서 master 브랜치의 파일 내용과 동일한 상태로 현행화 되어 있음을 알 수 있다.

ADO-git-handson# git checkout -b feature
Switched to a new branch 'feature'
ADO-git-handson# git branch
* feature
  master
ADO-git-handson# git log --oneline --graph
* 85354b7 (HEAD -> feature, origin/master, origin/HEAD, master) Modify README.md adding the comment
* c986055 Add a README.md
ADO-git-handson#

Git 브랜치 정책 및 Git Flow 관련 공식 문서
본 글에서는 간략하게 feature 브랜치를 생성하여 작업 후 master 브랜치에 Pull Request 하는 시나리오로 구성했다. Git 브랜치 정책과 관련한 상세 내용을 확인하려면 다음 2개의 문서를 확인한다.
- GitHub : 우리 팀에 맞는 Git Branch 전략 선택하기
- Azure DevOps : 분기 및 분기 정책 정보

이제 다시 터미널에서 README.md 파일을 열고 메시지 내의 오타를 수정한다. “brancch:에서 “c”를 하나 제거하여 저장한다.

vi README.md
README.md

ADO-git-handson# vi README.md
ADO-git-handson# cat README.md
Hello~ GIT~:)
# Now we can modify this file directly on the master branch :(
ADO-git-handson#

이제 다시 다음 명령을 수행하여 리모트 브랜치로 병합한다.

git commit -am "Modify README.md correcting the typeo in the comment"
git push --set-upstream origin feature

ADO-git-handson# git commit -am "Modify README.md correcting the typeo in the comment"
[feature a093d0f] Modify README.md correcting the typeo in the comment
 1 file changed, 1 insertion(+), 1 deletion(-)
ADO-git-handson#
ADO-git-handson# git push
fatal: The current branch feature has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin feature

ADO-git-handson# git push --set-upstream origin feature
Password for 'https://zerobig-devops4demo@dev.azure.com':
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 8 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 306 bytes | 14.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0), pack-reused 0
remote: Analyzing objects... (3/3) (39 ms)
remote: Validating commits... (1/1) done (73 ms)
remote: Storing packfile... done (36 ms)
remote: Storing index... done (48 ms)
To https://dev.azure.com/zerobig-devops4demo/20240809_AzureDevOps_Git_Demo/_git/20240815_AzureDevOps_Git_Demo
 * [new branch]      feature -> feature
Branch 'feature' set up to track remote branch 'feature' from 'origin'.
ADO-git-handson#

리모트 리포지토리를 새로고침하여 푸시 결과를 확인한다.

feature 브랜치의 업데이트를 감지하고 Pull Request를 시행하도록 메시지가 전시되었음을 확인할 수 있다.

우선 새로운 브랜치 feature를 선택하고 결과를 확인한다.

feature 브랜치의 README.md 파일에는 오타가 수정되어 반영되어 있음을 확인할 수 있다.

Create a pull request를 선택한다.

Reviewer를 추가하고 Create를 선택한다.

참고로 위에서 본인이 직접 Pull Request를 요청하고 검토 후 처리하지할 수 있도록 정책을 구성했으므로 자신을 Reviewer로 지정 가능하지만 여기서는 다른 검토자를 지정하였다. 당연히 사전에 프로젝트에 멤버로 추가 되어 있어야 한다. 멤버 추가에 대한 내용은 이 문서 를 참조한다.

검토자에게 다음과 같은 검토 요청 관련 메일이 수신 된다. View pull request를 선택하여 해당 페이지로 이동한다.

검토자는 해당 페이지에서 각 탭을 선택하여 Pull Request에 대한 자세한 내용들을 확인할 수 있다. File 탭을 선택한다.

파일 변경 전후의 내용을 직관적으로 비교 및 검토 할 수 있으며, 필요 시 검토 의견을 남길 수 있다. 내용이 적합하지 않을 경우, 보완 요청 의견을 남기고 Reject 을 수행할 수도 있다.

내용 상 문제가 없으니 Approve에 추가 옵션을 선택하고 Approve를 선택한한다.

Overview 탭으로 이동하면 1명의 검토자가 승인했음을 나타내는 메시지가 전시된다. Complete를 선택한다.

Complete merge를 선택하여 병합을 진행한다.

Pull Request가 성공되었음을 확인할 수 있다.

Repos > Files를에서 master 브랜치로 이동하면 변경 사항이 적용된 병합 결과를 확인할 수 있다.

Repos > Commits를 선택하여 master와 feature 두 브랜치의 내용을 비교하여여 살펴본다.

# feature

마지막 커밋 아이디 a093.. 임을 확인한다.

# master

마지막 커밋 아이디 defb..임을 확인한다. 즉, 하나의 커밋이 더 추가 되어 있음을 확인할 수 있다. 병합 옵션에 따라 결과가 달라 지는데 이 글에서는 기본값으로 진행하였다.

Pull Request를 생성 후 브랜치 병합 과정에서 프로젝트 상황에 따라 다양한 방식의 병합 옵션을 검토할 수 있다. Azure DevOps Repos의 Merge Type에 대한 추가 내용은 이 문서를 참조한다. 병합 기본 옵션 값은 Merge (no-fast forward
)”이다. 모든 커밋을 보전하며 비선형 기록으로 병합한다. 이 전략은 개발자가 토픽 브랜치에서 작업한 방식과 브랜치가 발전한 방향에 대한 완전한 통찰력을 제공하기 때문에 유용하지만 브랜치 기록에 커밋이 많으면 매우 장황할 수 있다. 병합 옵션에 대한 자세한 내용은 이 문서를 참고한다.

7. 브랜치 정리 및 새로 작업 준비하기

작업 브랜치(feature) 정리

이제 Pull Request 작업이 완료 되었으므로 필요 시 다음과 같이 feature 브랜치를 삭제할 수 있다.

참고로 feature 브랜치는 다음과 같이 Pull Request 병합 과정에서도 선택하여 제거가 가능하다.

더불어, 로컬의 터미널 상에서도 다음과 같은 명령을 수행하여 삭제가 가능하다.

먼저 현재 작업 브랜치를 확인하고 해당 브랜치가 feature 브랜치라면 master 브랜치로 이동한다.

git branch
git checkout master

ADO-git-handson# git branch
* feature
  master
ADO-git-handson# git checkout master
Switched to branch 'master'
Your branch is up to date with 'origin/master'.

다음 명령을 수행하여 로컬 feature 브랜치를 삭제한다. 해당 명령 수행 후 전체 브랜치 현황을 보면 리모트에 feature 브랜치는 아직 존재함을 알 수 있다.

git branch --delete feature
git branch --all

ADO-git-handson# git branch --delete feature
warning: deleting branch 'feature' that has been merged to
         'refs/remotes/origin/feature', but not yet merged to HEAD.
Deleted branch feature (was a093d0f).

ADO-git-handson# git branch --all
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/feature
  remotes/origin/master

다시 다음 명령을 수행하여 리모트 feature 브랜치를 삭제한다. 해당 명령 수행 후 전체 브랜치 현황을 보면 리모트에 feature 브랜치가 삭제 된 것을 확인 할 수 있다.

git push origin --delete feature
git branch --all

ADO-git-handson# git push origin --delete feature
Password for 'https://zerobig-devops4demo@dev.azure.com':
To https://dev.azure.com/zerobig-devops4demo/20240809_AzureDevOps_Git_Demo/_git/20240815_AzureDevOps_Git_Demo
 - [deleted]         feature
ADO-git-handson# git branch --all
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
ADO-git-handson#

새로운 변경 작업 준비하기

다시 새로운 변경 작업을 수행하기에 앞서 리모트 브랜치 변경 사항을 로컬 브랜치로 동기화 및 최신화 한다.

먼저 다음 명령을 수행하여 현재 로컬 master 브랜치의 커밋 이력을 확인한다.

git log --oneline

ADO-git-handson# git log --oneline
85354b7 (HEAD -> master, origin/master, origin/HEAD) Modify README.md adding the comment
c986055 Add a README.md

한편 리모트 master의 커밋 이력을 확인하면 2개의 커밋이 추가로 존재함을 알 수 있다.

다음 명령을 수행하여 현재 로컬 master 브랜치를 최신화 하고 결과를 확인한다.

git pull origin master
git log --oneline

ADO-git-handson# git pull origin master
Password for 'https://zerobig-devops4demo@dev.azure.com':
From https://dev.azure.com/zerobig-devops4demo/20240809_AzureDevOps_Git_Demo/_git/20240815_AzureDevOps_Git_Demo
 * branch            master     -> FETCH_HEAD
   85354b7..defbe0b  master     -> origin/master
Updating 85354b7..defbe0b
Fast-forward
 README.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
ADO-git-handson# git log --oneline
defbe0b (HEAD -> master, origin/master, origin/HEAD) Merged PR 60: Modify README.md correcting the typeo in the comment
a093d0f Modify README.md correcting the typeo in the comment
85354b7 Modify README.md adding the comment
c986055 Add a README.md
ADO-git-handson#

다음 명령을 수행하여 README.md 파일 내용이 최신으로 유지됨을 확인할 수 있다.

cat README.md

ADO-git-handson# cat README.md
Hello~ GIT~:)
# Now we can modify this file directly on the master branch :(
ADO-git-handson#

이제 새로운 변경 작업을 수행할 준비가 되었으며, 위에서 수행한 과정에 따라 변경 사항을 적용하고 Pull Request를 통해 master 브랜치에 병합하면 된다. :)

끝.