🐳 Docker study 6th

지난 몇 주간 Azure를 이용해 Docker를 공부해보며 꽤 많은 것들을 배웠다. 물론 머릿속에 정확히 내것으로 남아있는 것들이 많진 않지만 ㅎㅎ, 나중에 프로젝트를 하게 되면 Docker를 이용해보자 라는 용기는 생긴 것 같다!

내가 그간 배운 Docker는 로컬이 아닌 가상환경과 컨테이너를 이용해 더 나은 개발환경을 구축할 수 있고, 개인이 아닌 팀 프로젝트에서그 메리트가 더 확실해지는 것 같다. Docker를 이용해 하나의 프로젝트에 팀원 개개인의 컨테이너를 연결해 개발할 수 있다면? 보다 유연하고 효율적인 공동 작업이 가능해진다.

이번 Docker study 시리즈 마지막 포스팅에서는 관리자 권한 외에도 개별 팀원에게 권한을 부여하는 방법에 대해 실습해보려고 한다. 🏁

1. Add new user

현재 내 가상머신은 ‘Arielle’이 superuser(root)이다. 새로운 유저를 추가하는 방법은 간단하다.

sudo adduser <new_user_name> 로 새로운 유저를 등록해주면 된다. New password를 입력하라고 나오는데 적당히 설정해 주면 된다. sudo usermdod -aG docker dataengineer 명령어로 docker 그룹에 ‘dataengineer’를 추가해 docker 명령어를 사용할 수 있도록 했다.

🚨 참고로 sudo usermod -aG sudo dataengineer 을 이용해 신규 유저에게 ‘Arielle’과 같은 권한을 부여할 수도 있다. 위에서 Docker 그룹에 신규 유저를 추가해 주는 명령어랑 비슷해보이지만, 이 명령어의 사용은 지양 해야 한다!

관리자 권한을 갖게 되면 시스템의 거의 모든 작업을 할 수 있는 강력한 힘을 얻게 된다는 뜻이다. 물론 어떤 관점이냐에 따라 서버를 지킬 수 있는 힘이 되기도 하겠지만, 작은 버그로도 시스템 전체를 뒤흔들 수 있는 양날의 검 같은 존재가 되기도 한다.

1.1 Risk of Security Breaches

자율주행 회사 프로젝트에 막 합류한 주니어 엔지니어가 있다고 가정해 보자! 👩‍💻

당연한 이야기지만, sudo 그룹에 속하게 되면 중요 시스템 파일을 수정하거나 삭제할 수 있는 권한을 얻게 된다. 자율주행 프로젝트에는 너무나도 중요한 구성 파일과 설정이 포함되어 있다. 만약 주니어 개발자가 실수로 운영에 필요한 설정 파일을 지우거나 잘못된 명령을 실행하게 된다면..? 자율주행 시스템 자체가 버그 천지가 될 수도 있다.😱

특히 자율주행 차량은 하나의 실수로 안전이 위협받을 수 있는 매우 예민한 분야라 잘못된 명령 하나가 시스템 전반에 걸쳐 치명적인 결과를 초래할 가능성이 있다. 그래서 누구든 관리자 권한을 부여하는 건 매우 신중해야 한다!

1.2 Ambiguity in Accountability

자율주행 프로젝트는 각 개발자가 특정 역할과 책임을 맡아 작업하고 있을 것이다. 그런데 관리자 권한이 여러 사람에게 주어지면 누가 어떤 작업을 했는지 파악하기 어려워지는 문제가 생길 것이다. 예를 들어, 시스템에서 갑자기 예기치 못한 오류가 발생했다면 누가 어떤 설정을 변경 했는지 찾아야 하지만, 여러 사람이 관리자 권한을 갖고 있으면 추적이 복잡해 질 것이다.

이런 혼란을 피하기 위해선 각자의 역할에 맞는 최소한의 권한만 부여하고 필요한 경우에만 권한을 확장하는 것이 베스트일 것이다. 시스템 안정성과 개발의 신뢰성을 위해 누가 무슨 작업을 했는지 명확하게 기록하는 것은 선택이 아닌 필수다!

1.3 Granting Minimum Necessary Privileges is Safer!

IT 보안의 기본 원칙 중 하나는 최소 권한의 원칙이다. 필요 이상으로 권한을 부여하는 건 피하고 각자가 맡은 역할에 필요한 권한만 부여하는 것이다. 예를 들어, 주니어 엔지니어가 Docker를 사용할 수 있도록 Docker 그룹 권한만 부여해주면 주니어는 자율주행 프로젝트 환경에서 Docker 명령어를 문제없이 사용할 수 있다. (관리자 권한까지 줄 필요는 없다!)

아! 그리고 여담으로 개발자로서 자신에게 필요한 권한을 명확하게 요구할 수 있는 능력은 생각보다 꽤 중요한 것 같다. 개발자가 코드만 잘 짜면 되지 라고 생각할 수도 있지만 이 이야기를 하는 이유는 바로 정확한 권한 요청이 보안의 연장선에 있기 때문이다.

불필요한 권한을 요청하지 않음으로써 시스템의 보안 리스크를 줄일 수 있고, 덕분에 민감한 데이터나 설정이 불필요하게 노출될 위험도 줄어들게 될 것이다. 그리고 매니저도 팀원이 어떤 권한이 필요한지 정확히 파악할 수 있어 업무에 필요한 권한을 적시에 제공하며 협업의 효율도 크게 높아지게 된다.

보안과 효율성, 두 마리 토끼를 잡을 수 있게 되는 것이다! 🐇

2. Let new user access to VM with xrdp

<🐳 Docker Study 2nd, 3. Connect to GUI via RDP (MAC)> 에서 XRDP를 이용해 데스크탑을 이용해 가상머신에 접속할 수 있도록 했다.신규 유저(dataengineer) 역시 동일한 과정을 진행했다. 다른 점은 그룹 기반 권한을 통해 특정 그룹의 유저에게만 접근을 허용하도록 구성한 점이다. (기존 내용과 비교해보는 것을 추천한다!)

가장 먼저 sudo groupadd tsuser 으로 tsusers 그룹을 생성해 주었다. 이후 sudo usermod -aG tsusers dataengineer 로 ‘dataengineer’, sudo usermod -aG tsusers Arielle‘Arielle’을 tsusers 그룹에 추가해 주었다. (명령어 입력 순서는 상관 없음!)

그 다음에는 sudo nano /etc/xrdp/sesman.ini 파일을 수정해 주었다. [Security] 섹션에서 TerminalServerUsers=tsusers 확인하고, AlwaysGroupCheck=true 로 변경해 주었다. (하단 사진 참고👇)

이후 su dataengineer 실행 시, Arielle@kaggle-linux-gpu-vm → dataengineer@kaggle-linux\gpu-vm으로 가상머신의 유저가 변경되는 것을 확인할 수 있다. (su : switch user)

참고로 echo xfce4-session > ~/.xsession 의 경우 사용자가 XRDP와 같은 원격 접속을 통해 로그인할 때 자동으로 XFCE 데스크탑 환경을 시작하도록 하는 역할을 한다.

여기까지 새로운 유저(dataengineer)를 생성하고, 유저에게 Remote Desktop Protocol(XRDP)로 접근 가능하도록 준비해주었다. 다음 단계는 이 새로운 유저에게 KEY를 사용해 가상머신에 접근할 수 있도록 설정해 주어야 한다. <3. ssh key creation by admin> 으로 계속 진행해주면 된다! 👊

3. ssh key creation by admin (Admin Role)

기존에 가상머신에 접근하기 위해서 ssh폴더를 생성 후 .pem 파일의 가상머신 키를 저장해 놓았었다. 새로운 유저 역시 마찬가지로 ssh폴더를 생성 후 기존 키에 대한 권한을 부여해 주어야 한다. 여러 단계가 필요하지만 사실 그렇게 어렵지 않아서 하나씩 천천히 따라가면 쉽게 진행될 것이다!

1️⃣ 새로운 유저에 대해 mkdir ~/ssh ssh폴더를 생성해 주었다.

2️⃣ touch ~/ssh/authorized_keys 명령을 사용해 ssh 내부 디렉토리에 authorized_keys 파일을 만들어 주었다.

3️⃣ chmod 700 ~/.ssh 로 해당 폴더에 대한 권한을 설정했다.

참고로 여기서 700에 대해서 잠깐 이야기해보자면! 권한의 허용 범위에 따라 이 숫자가 달라질 수 있다. 700은 읽기(4), 쓰기(2), 실행(1)의 권한을 더해서 만든 것이다. 조금만 더 자세히 이야기해보면 아래와 같다!

• 7 (4 + 2 + 1) : 소유자에게 읽기, 쓰기, 실행의 모든 권한을 부여 (현재 유저)
• 0 : 그룹에는 접근 권한이 없음 (현재 유저가 속한 그룹)
• 0 : 다른 사용자에게도 접근 권한 없음 (그 외의 사용자)

즉, dataengineer 유저에게만 해당 폴더를 열어보고 수정하고 실행할 수 있는 것이다. 이렇게 이해하면 추후 내가 특정 유저에게 권한을 세밀하게 부여할 수 있을 것이다!

4️⃣ authorized_keys 파일에는 chmod 600 ~/.ssh/authorized_keys 으로 보안성을 높여 주었다. 해당 파일은 실제 SSH Key 리스트가 들어 있다. 따라서 600(4+2)로 실행 권한은 주지 않았다.

일단, 나는 여기서 왜 ssh처럼 700권한을 부여하지 않았는지 궁금했다. 그래서 조금 더 찾아보니 사실 당연한 이유였다. authorized_keys 파일에는 SSH 접속을 허용하는 공개 키 목록만 저장되어 있다. 이 파일 자체가 실행되는 프로그램이나 스크립트가 아니라는 것이 포인트다! 그래서 실행 권한을 줄 필요가 없고 오히려 주는 게 보안 측면에서 불필요하게 권한을 넓히는 일이 되버린다. 따라서 읽기와 쓰기 권한만 설정하면 충분하고, 위에서 설명한 Principle of Least Privilege(최소 권한의 원칙)과 딱 맞아 떨어진다! 🔐

5️⃣ ssh-keygen -t rsa -m PEM 명령어로 dataengineer 사용자만의 PEM 형식의 새로운 SSH 키 쌍을 생성해 주었다. ‘Enter file in which to save the key…’ 라고 키를 저장할 파일을 입력하라는 메세지가 나올텐데, Enter키를 눌러 기본 위치(/home/dataengineer/.ssh/id_rsa)를 선택해주면 된다. 최종적으로 .pub으로 끝나지 않는 개인키와 .pub으로 끝나는 공개 키가 생성되니 확인해 주면 된다!

<1️⃣~5️⃣ 아래 사진 참고👇 >

6️⃣  nano ~/.ssh/authorized_keys 로 해당 파일에 접근해보면 아무것도 없을 것이다. 이 곳에 위에서 5️⃣ 에서 생성한 공개 키(public key)를 복사해 주어야 한다!

cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys 명령어로 공개 키를 복사해 주면 된다. 실행 화면을 보고 이야기 해보록 하자면, 현재 .ssh 폴더에 authorized_keys, id_rsa, id_rsa.pub 파일이 있는 것을 확인할 수 있다. 각각의 파일 특징은 아래와 같다.

• authorized_keys
  • id_rsa.pub : public key(공개 키)
• id_rsa : private key(개인 키)

만약 외부에서 id_rsa라는 private key를 이용해 외부에서 가상머신에 접근하려고 할 때, private key와 authorized keys파일 내부에 있는 public key와 매칭시켜 연결 혹은 거절 하는 방식으로 진행된다.

7️⃣ 6️⃣에서 공개키를 authorized_keys로 복사 해주었으니 이번에 nano ~/.ssh/authorized_keys 실행시켜보면 key 내용이 들어있을 것이다.

전체를 복사한 후 kaggle-linux-gpu-vm_key_dataengineer.pem 이라는 파일로 ssh 폴더에 신규 유저만의 키를 생성해 주었다.

8️⃣ ’dataengineer’ 유저로 실제 해당 가상머신에 접속해보면 정상적으로 실행됨을 확인할 수 있을 것이다! (ssh -i <신규 유저 pem키> <유저 이름>@<가상머신 IP>)

4. User Setting: ssh key creation by admin (User Role)

이제 새로운 유저, dataengineer가 가상머신으로 작업을 진행하기 위해서는 로컬과 가상머신을 연결해야 한다. 사실 로컬에서 가상머신을 연결하는 과정은 이미 기존 포스팅에서 설명한 내용이다. 정리 된 내용은 🔗 Remote Tunnel Connect 링크에서 확인해주면 된다!

🔗 Remote Tunnel Connect (👉관련내용 참고)

• ssh 연결
• RDP(Remote Desktop Protocol) GUI 연결
  • Chrome 설치
  • Visual Studio Code 설치

✋ 여기서 잠깐! 신규 유저 설정 시 알아야 할 점

일반적으로는 새 유저가 가상머신에 접속하려면 Chrome이나 VSCode 같은 툴이 필요할 수도 있는데, 이 경우는 별도로 설치하지 않아도 된다! 왜냐하면 관리자(Arielle)가 이미 설치했기 때문이다.

이게 무슨 말인가 싶을 수 있다. 신규 유저는 소프트웨어를 설치한 적이 없는데 말이다.

그 이유는 관리자가 Chrome과 VSCode를 이미 시스템 레벨에 설치했기 때문에 신규 유저도 이 소프트웨어들을 그대로 사용할 수 있다. 이 말인즉, 시스템에 한 번 설치된 소프트웨어는 여러 유저가 공용으로 사용할 수 있는 상태가 되는 것이다.

계속해서 반복되는 말이긴 하지만 기억할 점은, 관리자 권한을 새 유저에게 부여하지 않는다는 원칙이다.(반복되는 것을 보니 꽤 중요한 부분임!) 관리자는 시스템 전체의 설정을 변경할 수 있지만 일반 유저에게는 불필요한 권한을 주지 않는 것이 보안을 유지하는 데 중요한 점을 다시한번 머릿속에 정리하면 좋겠다.

나는 MAC을 사용하고 있으니 Window App을 통해 dataenginner 유저로 접속해주었다. 이후 VSCode → Account → Turn on Remote Tunnel Access → Install as a service → Sign in with Github (Use weaker encryption 버그 참고) 으로 진행해 주었다.

로컬의 VSCode로 돌아와 dataenginner의 Tunnel 방식으로 접속해 주었더니 정상적으로 접속됨을 확인했다!

5. The connection between autonomous driving and Docker 🚗🤖

Docker 시리즈 마지막 포스팅이니 만큼, Docker를 공부하게 된 가장 큰 이유인 자율주행 개발의 특이점에 대해 이야기해보려고 한다. 자율주행을 공부해보자! 라고 마음 먹었을 때 엄청나게 사명감 있는 이유는 없었다. 솔직히 말하면 그저 사람 없이 주행하는 자동차를 보고 있자니 도파민이 터져서 여기까지 왔달까 😂?

아무튼 이 세상에 처음 들어와서 공부를 해본 소감은.. 정말이지 다양한 센서들과 그에 따른 엄청난 양의 데이터들까지.너무나도 다양한 시스템들이 실시간으로 상호작용해야 하는 구조였다. 왜 자율주행 옵션이 비싸고 빨리 상용화되지 않는지에 대해 바로 수긍하게 되었다.

대체 이런 시스템을 어떻게 처리하고 있는가 찾아보니 Docker와 같은 가상화, 컨테이너 기술로 자율주행 개발의 복잡성을 해결하는 것 같았다. 가장 먼저 센서들! Lidar, Rader, Camera, GPS는 일반인들도 알고 있는 자율주행의 센서들이다. 그런데 이 센서들이 처리하는 데이터의 용량이 정말 어마무시한데, 이 때 Docker 기술을 사용해 센서 혹은 시스템에 필요한 라이브러리나 종속성(dependencies)을 컨테이너별로 관리할 수 있어 다른 센서들과의 충돌 없이 독립적으로 작동 할 수 있다.

실제로 요즘 센서 처리의 트랜드는 Sensor Fusion(센서 융합)이다. 각기 센서마다 장단점들이 명확해 장점들을 최대한으로 발휘할 수 있도록 시스템을 처리하는 것이다. 주간에는 카메라를 이용해 객체를 탐지하고, 악천후 혹은 야간에는 다른 센서들을 쓰는 것이 훨씬 더 안전하고, 경제적인 것이 핵심이다.

이렇게 환경의 영향을 많이 받는 자율주행 특성 상 실제로 다양한 툴과 라이브러리들이 요구되고 있는데 심지어 이 모든 것들이 Sensor Fusion에 맞게 동시에! 작동해야한다. 이때 Docker는 주행 환경 별로 컨테이너 이미지로 저장해 두고, 필요할 때마다 불러와 사용할 수 있다. 이게 내가 느낀 자율주행 엔지니어가 Docker를 배워야 하는 가장 큰 이유다.

빅데이터, DB 수업을 듣고 혹은 공부해봤다면 Roll Back(롤백)에 대해 들어 봤을 것이다. 시스템이나 소프트웨어 업데이트 이후에 발생하는 문제들을 이전 버전으로 되돌린다는 개념인데, Docker의 이미지 버전 관리로 쉽게 롤백 할 수 있다. (이 부분은 시리즈에서 다루지 않은 내용이라 더 공부해보려고 한다.)

Tesla, Waymo 같은 자율주행 기업들은 실제로 소프트웨어 업데이트를 통해 주행 안정성을 높이고 있는데, 약간씩 그 시기는 회사마다 다른 것 같다.Tesla는 OTA(Over-the-Air) 방식으로 차량이 실시간 데이터로 자가학습 업데이트를 진행하기에 꽤 잦은 편이고, Waymo는 주행 구역 별로 일정한 주기에 따라 업데이트를 진행한다.

핵심은 자율주행 소프트웨어는 꾸준한 업데이트와 관리가 필수라는 것이며 이 때 도커의 이미지 Roll Back 🔄 기능이 업데이트 시 발생하는 문제를 빠르게 되돌려 시스템의 안정성을 유지해주기도 하고, 신규 업데이트를 적용하기 전에 다양한 주행 환경에서 충분히 테스트 해도 원래 상태로 쉽게 되돌릴 수 있다.

이 외에도 다양한 이점들이 있겠지만 이정도로만 정리해도 자율주행 엔지니어에게 Docker는 필요충분조건이 아닐까 생각한다.

이번 Docker study 6th을 끝으로 도커 시리즈가 끝났다. 시리즈가 끝났다고 한들 내가 도커에 대해 모든 걸 알게 되었다고 절대로 절대로 생각하지 않는다. 오히려 이제 내가 추후 도커의 어떤 세부적인 시리즈를 준비해야 하는지 알게 되었다고 말하는 게 더 정확할 것 같다.

Microsoft Certified: Azure AI Fundamentals AI와 머신러닝의 기본을 바탕으로 클라우드 환경에서 배포하는 과정을 다룬 자격증이다. 시간 지나면 잊어버릴게 뻔하니 Docker에 대해 머리속에 조금이나 남았을 때 한번 도전해보려고 한다.🛫

Reference

What is the Principle of Least Privilege?_Google Cloud Tech

Fusion of Imaging Radar and Camera Sensors: Elevating Autonomous Vehicle Reliability

Tesla vs Waymo: The Battle for Autonomous Vehicle Leadership