AD
AD 는 권한부여, 인증을 담당 하고 있기 때문에 관리자(A) 관리자 외에 사용자(B)가 AD에 소속 되어 있다면 A는 B에게 권한을 부여해서 A가 B에게 "너는 1구독에서 작업해" 라고 부여 한다면 B는 1구독에서 작업이 가능하다.
하나의 AD에 여러 구독을 묶을 수 있다.
외부에서 Guste 계정으로 제3자가 추가(MS직원) 되고 AD에 소속된 내부 직원들은 AD에게 인증을 받지만 Guste 추가된 사람들(MS직원)은 실제 구독은 AD에서 부여 하지만 인증은 MS AD에서 하게 된다.
==> 즉 나의 AD에서 제 3자를 Guste 계정으로 추가를 할 수도 있지만 초대를 해서 접근권한은 나의 구독에서 작업을 할 수 있도록 권한을 줄 수도 있고 인증은 MS에서 받을 수 있다는 것이다.
Azure Active Directory Connect (AAD Connect)
온프레미스 AD를 Cloud로 확장 하기 위해 직원 (ex.300명)을 Cloud로 옮기려면 휴먼 에러가 날 수도 있기 때문에 Microsoft 에서는 온프레미스 AD와 Azure Cloud의 AD를 동기화 할 수 있는 기능이 존재한다.
ADD 와 온프레미스 AD와의 차이점
1. ADD는 웹 표준에 맞게 설계 되었다. (웹 인증 기반으로 설계 되었다)
1-1. 인증에는 WS-Federation, OpenID Connect 권한 부여용으로 OAuth을 사용한다.
Demo
1. 사용자 추가
사용자가 삭제 되면 삭제된 사용자(미리보기) 탭에 30일동안 저장되어 있으므로 실수로 삭제 하거나 했을 경우 복구가 가능하다.
2. 그룹
사용자(A)의 속성값이 설정 되어 있는 상태에서 동적 그룹을 만든다.
사용자(A)의 속성값은 IT 일 경우 동적 그룹이 3개가 있다
Group team : IT
Group team : F
Group team : D
일 경우 사용자의 속성값 기반으로 그룹을 만들 수 있다.
즉 사용자 (A)의 속성값이 현재 IT이므로 IT 그룹에 추가되지만 부서이동을 해서 개발로 간다면 Group team D로 그룹으로 자동으로 이동된다.
거버넌스 및 규정준수
pysical layer
1. Geograpby (지리)
2. Region (지역)
3. Data Center (데이터 센터)
4. Resource (리소스)
Logical layer
1. 관리그룹
2. 구독
3. 리소스 그룹
4. 리소스
Region의 경우는 DR때문에
구독의 이름은 변경이 가능하다. (이름을 바꿀 경우에는 10~15분 정도 시간이 걸린다.)
사용자가 구독을 만들면 구독당 AD가 만들어 지는데 사용자는 이미 사용중인 AD가 존재한다고 하면 여러 구독을 한 AD로 묶을 수 있다.
왜 관리그룹을 통해 구독이 관리 되고 리소스 그룹이 관리 되고 리소스가 관리 되어야 할까 ?
온프레미스 AD는 지표를 통한 정책 배포가 되지만 Azure에서는 불가능 하다
그래서 Azure 구독에서 Policy라는 정책을 만들 수 있다.
ex) 구독에 어떠한 정책을 만들때 태그를 달아야 만들 수 있게 조건을 걸 수 있다.
또는 vm을 만들 때 20코어 이하만 만들수 있도록 한다 .
또는 한국 중부에만 리소스를 만들 수 있다.
참고로 구독은 VM을 무한정 만들 수 없다.
예를들어 대형 프로젝트를 진행 할 경우 한 구독당 VM을 4개만 만드는게 가능하지만 현 프로젝트에서는 6개가 필요할
경우 구독을 하나 더 생성하여 두 4개 2개 의 VM을 만들어 두 구독을 연결 해주는 방법이 있다.
정책 만들기
이후 적용을 해주면 된다.
여러 구독이 있는 경우 구독마다 정책을 적용하기 힘들기 때문에
그룹을 하나 만들어서 정책을 적용 하고자 하는 그룹을 새로만든 그룹에 넣어주고 그 그룹에 정책을 반영 해주면 된다.
정책은 root에 회사전체에 대한 정책을 적용하고
하위 부서 종류가 IT, F , D 가 있다 하면 IT에만 정 책을 추가로 적용 한다면 ROOT + IT 에 정책이 적용되고 IT정책을 F로 옮기게 되면 IT에는 ROOT 정책만 적용 되고 F에 ROOT + IT 정책이 된다.
즉 IT와 F, D는 ROOT의 정책을 상속 받게 된다.
태그
태그는 비용 추적할때 용이 하다
예를 들어 한 구독안에 프로젝트가 3개가 있다 이럴때 태그를 확인 하여 비용을 산출 할 수 있다.
또는 태그를 이용하여 자동화 옵션을 걸 수 있다.
RBAC (Role Based Access Control) : 권한을 부여할 수 있다.
AAD를 생성한 소유자는 구독을 혼자 관리하기 어렵기 때문에 관리자를 한명 추가 하게 된다.
추가된 관리자는 기여자로 분류가 되고 둘의 차이점은 다음과 같다.
소유자 : 다른 사용자에게 권한을 부여할 수 있다.
기여자 : 다른 사용자에게 권한을 부여할 수 없다.
Policy : 관리그룹 , 구독 , 리소스 그룹에만 배포가 가능하다
※RBAC과 다른 개념
Azure 관리
관리하기 위한 도구
1. Azure Portal
2. Power Shell
3. CLI
※2번과 3번은 문법에 관한 차이가 있고 거의 동일하다
4. REST API
5. 탬플릿
Azure Resource Manager가 위의 관리 도구의 요청을 받아서 Resource를 생성하게 된다.
리소스 : 애저의 단일 서비스 인스턴스
리소스 그룹 : 리소스의 논리적 그룹
리소스는 리소스 그룹 하나에만 포함 될 수 있다.
그룹의 이름은 변경이 불가능 하다.
그룹은 다양한 지역의 리소스를 포함할 수 있다.
리소스는 잠글 수 있다.
읽기 전용도 가능하다.
리소스는 이동이 가능하다 (이동중에는 약간의 다운타임이 발생할 수 있다.)
삭제는 리소스 하나씩 삭제도 가능하고 여러개 한번에도 가능하고 리소스 그룹 자체를 삭제 할 수도 있다.
Power shell 은 처음에 windows 에서만 작동했다.
Linux에서도 사용하기 위해 나온 것이 CLI
Storage Acount : 영구 스토리지
shell들을 수행할 수 있는 vm이 하나 생성이 된다.
해당 vm이 SA와 연결되어 입력되는 shell내용들을 수행한다.
이후 shell script를 끄면 vm은 삭제 된다, 하지만 SA안에 흔적들은 남아있다.
Power Shell , CLI :명령적(코드를 하나하나 써줘서 배포)
템플릿 :
선언적(변수에 의해서 코드가 자동으로 배포)
일관성이 향상된다.
재사용이 가능하다.
모듈식이며 연결이 가능하다.
템플릿의 5가지 모듈
- 스키마.
- 매개변수(parameter) : 외부에서 입력받는 입력 값
- 변수(variables) : 내부에서 사용되는 변수
- 템플릿 전체에서 사용되는 값을 정의 한다.
- 템플릿을 보다 쉽게 유지 관리 할 수 있다.
- 템플릿 기능(functions)
- 재사용 가능한 절차를 정의한다.
- 템플릿을 보다 쉽게 관리할 수 있다.
- 템플릿 리소스
- 배포를 구성하는 Azure 리소스를 정의한다.
- 템플릿 출력 (outputs)
- 템플릿 실행 시 수신할 정보를 정의한다.
'클라우드 > Company' 카테고리의 다른 글
Azure VM port 변경하여 ssh 접속(ubuntu) (0) | 2023.01.06 |
---|---|
Azure 3Tier /계속 수정 예정 (0) | 2022.12.19 |
Azure 공부2일차 (0) | 2022.11.15 |