개요

1주차 온보딩 직후, oo님의 질문에 대한 답을 하기로했다.

질문은 다음과 같다.

“폐쇄망에서 SDK 라이브 패키지를 설치를 하고 내 터미널에서 gcloud oauth login인증을 받으려면 어떻게 해야하는지?”

이 물음에 대해 답변을 하기 위해선 폐쇄망에 대한 개념 확립이 필요했다.

그래서 다음과 같이 목차를 선정하였다!

목차

• 폐쇄망이란?
• SDK 라이브 패키지 설치 방식?
• gcloud oauth login 인증?

아마 하나씩 알아보면 질문에 대한 해답을 알 수 있을것이라 생각했다. 렛츠꼬

---

폐쇄망이란?

내가 생각하는 폐쇄망은 단순 “인터넷이 안되는 공간”으로 알고 있을 뿐이었다.

정의는 다음과 같다.

폐쇄망(Closed Network 또는 Air-Gapped Network)이란 외부 인터넷과 물리적 또는 논리적으로 완전히 분리되어 외부에서의 무단 접근이나 내부 정보 유출을 차단한 네트워크 환경

SDK 라이브 패키지 설치 방식?

여기서 그럼 질문과 같이 의문이 생긴다.

“외부 네크워크 망과 연결도 안되는 폐쇄망 환경에서 어떻게 라이브러리를 설치하지?”

여기서 두가지 방식이 존재한다.

• 외부에서 패키지를 받은 뒤 폐쇄망으로 반입
• 회사 내부에 패키지 저장소를 두기

방식 1 . 외부에서 패키지를 받은 뒤 폐쇄망으로 반입

말 그대로 폐쇄망 안에서 다운로드하지 않고, 밖에서 다운로드해서 승인된 반입 절차를 거쳐 안으로 가져온다.

Google 문서에서도 Client Library를 패키지 매니저로 설치하거나 다운로드 후 수동 설치하는 방식을 안내가 있다.

간단하게 보자면

인터넷이 되는 환경에서 필요한 패키지와 dependency를 먼저 다운로드 한다.

pip download google-cloud-bigquery -d ./packages

그럼 아래와 같이 필요한 wheel 파일들을 확보가 가능하다.

 ├── google_cloud_bigquery-....whl
 ├── google_api_core-....whl
 ├── google_auth-....whl
 ├── protobuf-....whl
 ├── grpcio-....whl
 └── ...

그 다음 회사의 보안정책에 따른 반입절차를 거쳐 폐쇄망으로 옮긴다.
그리고나서 인터넷을 보지 않고 로컬 파일만 사용하도록 설치하면 된다.

방식 2. 회사 내부에 패키지 저장소를 둠

해당 방식은 회사 내부에 Repository를 구축하는 것이다.

→ 사내에 PyPI 역할을 하는 저장소를 두는 방식

PypI(Python Package Index) : Python을 위한 오픈소스 패키지 저장소*

GCP 쪽에서는  ⁠Artifact Registry의 Python package repository를 Python 패키지 저장소로 사용할 수 있고, pip의 index-url을 해당 저장소로 설정하는 방식도 공식적으로 지원한다 (출처)

하지만, 질문의 의도를 봤을 때 2번처럼 이미 패키지를 설치하고 쓰는 상황이라면 안나왔을 것 같은 생각에

1번 상황(외부에서 다운로드를 받고 들어오는 방식)을 염두하고 글을 이어나가겠다.

일반 환경에서의 Google Cloud CLI 설치

구조는 다음과 같다.

내 PC
 │
 ├─ ① gcloud CLI 설치
 │
 │       ↓
 │
 ├─ ② gcloud auth login
 │       ↓
 │    Google OAuth
 │       ↓
 │    Credential 저장
 │
 └─ ③ gcloud 명령 실행
         ↓
      Google Cloud API

근데 폐쇄망은 1번 부터 막힌다ㅎ

그래서 Google은 Versioned Archive 방식으로 각 gcloud CLI 릴리스에 대해 압축된 설치본을 제공한다.(출처)

순서는 다음과 같다.

1. 인터넷이 되는 PC에서 파일 다운
2. 회사에서 정한 보안 반입 절차를 통과
3. 폐쇄망 안에서 압축풀기(./google-cloud-sdk/install.sh)

하지만, 마지막 절차가 남았다.

gcloud oauth login 인증?

이전 과정에서 파일을 폐쇄망 안에서 압축을 성공적으로 풀었다고 가정해보자.

일반적으로gcloud auth login 인증을 받으려면 아래와 같다.

gcloud auth login
       ↓
Google OAuth
       ↓
브라우저
       ↓
Google 로그인
       ↓
Credential

$\rightarrow$ 그치만 폐쇄망 환경이니까 브라우저 접근이 안되지 않는가?

그래서 Google이 제공하는 방법은 다음 명령어가 있다.

gcloud auth login --no-browser

→ `--no-browser`는 인증을 다른 PC에서 수행한다는 뜻

즉, 브라우저 연결이 가능한 다른 PC에서 인증을 수행한뒤, 폐쇄망 내의 환경으로 해당 인증을 전달해준다.

여기서 또 의문점이 생겼다.

“ 인증 결과 전달은 어떻게 하지? 폐쇄망인데”

네트워크를 통해 폐쇄망 PC로 전송한다는 뜻이 아닌, 사용자가 인증 결과로 나온 문자열(URL 또는 인증 코드)을 폐쇄망 터미널에 직접 입력하는 방식이며, Google이 공식적으로 지원한다(출처)

$\rightarrow$ 구글은 다 염두에 두고 있군

“전달” 방식을 도식화 해보면 다음과 같다.

폐쇄망 PC                         인터넷 PC

gcloud 실행
    │
    ├── OAuth URL ───────────────→ 브라우저에서 URL 입력
    │                                   │
    │                              Google 로그인
    │                                   │
    │                              인증 코드 획득
    │                                   │
    │
    ←──── 인증 코드 ─────────────────────┘
    │
    ▼
터미널에 코드 입력

여기서

“폐쇄망인데 구글이 어떻게 인증 되었다고 판단할 수가 있는거지?”

라는 의문이 들 수 있다.

몰론 완전히 폐쇄망이면 교환이 이루어지지 않는다.

즉, “인터넷 웹사이트/PyPI는 막혔지만 Google의 특정 endpoint는 허용” 이라면 해당 앤드포인트로 통신이어야 한다.

폐쇄망 PC
   │
   ├────→ pypi.org                 ❌
   ├────→ github.com               ❌
   ├────→ naver.com                ❌
   │
   ├────→ oauth2.googleapis.com    ⭕
   └────→ bigquery.googleapis.com  ⭕

이렇게 찾아보니 “높은 신뢰도를 기반으로 설계된 인프라” 라는 생각이 들었다.

담엔 "BigQuery 사용시 필요한 API통신 방법"이 별도로 구축되어있는지는 다음에 자세히 알아보겠다(+ 온프레미스 등)

끝 (내 주말도 끝)