circleci, docker, ssh 그리고 github 연동의 슬픈 이야기

github에 circleci를 연동하는 과정에서 겪었던 슬픈 이야기를 조근 조근 읊어보려 한다.

ssh fingerprint 와 known_hosts

ssh는 비대칭키를 사용하는데, 이때 host의 암호키에 대해서 fingerprint를 확인하는 절차를 거친다. ssh가 널리 사용되는 만큼 자주 접할 수 있는 그 질문! "니가 접속하려는 host의 암호키 fingerprint가 이건데, 맞아?" 솔직히 이 fingerprint 진짜 대조해 보는 사람이 있을까 싶지만, 그런 헛점을 이용하면 아이디 / 패스워드 빼먹는 일은 별로 안 어려울 것 같다는 생각도 든다.

어째든, host의 암호키 fingerprint를 확인하는 절차를 거친 후에 ssh 연결이 진행되는데, 확인된 공개키는 ~/.ssh/known_hosts 파일에 기록되어서 다시 확인하는 절차가 생략된다.

CI의 특성상 컨테이너에서 매번 새롭게 접근할 때마다 그 fingerprint를 확인 할 수 없으므로 조치를 취해야 한다.

1. fingerprint를 사전에 입력해둔다.

• echo {fingerprint} > ~/.ssh/known_host
• 무식해 보이지만 확실한 경우만 예외를 적용한다는 점에서 아랫것들보다 나을 수 있지만, 귀찮다.

2. 공개키를 스캔해서 known_hosts 파일에 넣는 사전 절차를 추가한다.

• ssh-keyscan -H [host, ip] >> ~/.ssh/known_host
• CI의 특수한 케이스라면 차라리 아랫것을 쓰겠다. 네크워크 리소스 낭비다.

3. 공개키 확인 절차를 무시하도록 설정한다.

• echo " StrictHostKeyChecking no" >> ~/.ssh/config

docker image 는 root 유저

docker 이미지는 root user로 사용하는 것이 기본이다. home의 위치도 /root이다. 여기서 기본은 일반적이란 뜻이다. 물론 root가 아닐 수도 있고, home의 위치도 다른 곳으로 설정되어 있을 수 있다. 그럴 경우, 문제가 왕왕 생길 수 있다. 누군가는 그 설정 때문에 당황하게 될 수도 있다.

home은 우리 집이어야 한다

docker 이미지를 생성할 때 root가 아닌 다른 유저를 추가하고, 해당 유저로 실행되도록 설정 할 수 있다. 하지만 그 docker 이미지를 사용하는 시스템이 계정을 변경 할 수도 있다. 계정은 변경되었지만 home의 위치는 변경되지 않았다면? ~/.ssh 이렇게 접근할 때 엉뚱한 곳에 접근하게 된다. 최악이다! circleci 는 docker 설정과 무관하게 root 계정으로 로그인되지만 정작 home의 위치는 따로 조정하지 않아서...고통을...

RUN groupadd -g 999 appuser
RUN useradd -r -u 999 -g appuser appuser

USER appuser

https://movie.daum.net/moviedb/main?movieId=130920

github의 deploy key 와 user key

github에 ssh 연결을 할 때 사용되는 키는 2가지 종류가 있다. deploy key와 user key

deploy key는 프로젝트 단위로 설정할 수 있고, user key는 사용자 계정 단위로 설정이 가능하다. 아주 직관적이다. 다만, 같은 deploy key를 서로 다른 프로젝트에서 사용할 수가 없다.

https://velog.io/@zechery/CICD-w-CircleCI-Docker-Hub-AWS-EC2

circleci와 연동 할 때는 checkout key 설정과 SSH Permissions 설정이 있는데, SSH permissions에 private key를 추가해서 사용하는 방식은 github 이외의 시스템에만 적용해라. github는 checkout key 설정으로 해결하는 것을 권한다. circleci에서 키를 관리하므로 간편할 뿐만 아니라 원인 모를 오동작으로부터 보다 자유롭다. 아래 가이드 대로 SSH Permissions에 다른 repo deploy key를 설정해서 사용해 보았지만, 제대로 동작하지 않았다. 우선 순위가 있는 건지...checkout key에서 키를 모두 삭제해야 적용이 되는데, 다 부질없다. 단순한게 짱이다.

GitHub and Bitbucket Integration

github page는 submodule도 된다고 했는데

된다고 해서 야심차게 submodule을 사용해서 repo 간에 느슨한 연결을 구성했지만, 막상 잘 되지 않았다. 물론 enterprise 버전이다. 나에겐 그것을 바로 잡을 오지랖력이 남아있지 않았다. 항상 느끼지만, enterprise가 더 좋아야 할 것 같은데, 안 좋은게 더 많은 것 같다. 고인물은 썩기 마련이지...

교훈

많은 사람이 사용하지 않는 시스템 또는 많은 사람들이 사용하지 않은 기능은 각오가 남달라야 한다. 내가 마루타가 될 확률이 매우 높다. Advanced 기능을 사용하기 전에는 다른 사람들의 경험을 먼저 훑어보자. 좋은 벤치마크 대상은 많을 수록 좋다. 감사한 마음으로 겸손하게, 영리하게 선구자들을 이용하자!

슬픈이야기는

바쁘게 열심히 움직였는데, 결과가 생각만큼 안 나와서 슬펐다. 집에 와서 머리를 감다 생각이 났다. 눈에 보이는 결과는 기대 이하지만, 내가 얻은 것은 생각보다 더 많구나. 삽질을 슬퍼하지 말고, 분노하지 말고, 긍정 알약 하나 먹고, 내일도 화이팅!