Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't delete unused KeyPair in AWS #480

Closed
powerkimhub opened this issue Oct 8, 2021 · 30 comments · Fixed by #508
Closed

Can't delete unused KeyPair in AWS #480

powerkimhub opened this issue Oct 8, 2021 · 30 comments · Fixed by #508
Assignees
Labels
bug Something isn't working CloudDriver

Comments

@powerkimhub
Copy link
Member

@dev4unet

What happened

[재현절차]

  1. Spider를 통해서 AWS VM KeyPair 생성하면,
  • cb-spider/cloud-driver-libs/.ssh-aws 위치에 다음과 같이 키 파일이 생성되고,
    255e2c4cd5e4f1ba87cbed3b6911519d4a8f9ce5.pem  255e2c4cd5e4f1ba87cbed3b6911519d4a8f9ce5.pub
    
  • AWS에 키페어가 생성됩니다.
    image
  1. 꼬인 상태 재현을 위해서, Spider를 종료하고 메타정보를 삭제 후 Spider를 가동시킵니다.
  • 꼬인 정보를 해결하고자 관리모드로 KeyPair를 확인해보면,

  • 아래 그림에서와 같이 cb-spider/cloud-driver-libs/.ssh-aws 에 관련 파일이 존재하는 목록만 보입니다.
    image

  • cb-spider/cloud-driver-libs/.ssh-aws 에 관련 파일도 삭제하면,

    • Spider에서 보이지 않기 때문에 삭제할 수 없고, AWS Console에서만 삭제할 수 있습니다.

image

[질문]

  • 예전처럼 Spider를 통해서 꼬인 정보를 관리할 수 있도록
  • 다음 위치에 관련 파일 여부에 상관 없이 목록을 올려주실 수 있나요?
    • cb-spider/cloud-driver-libs/.ssh-aws
  • 삭제 요청시 파일만 존재하면 파일만 삭제해서 clean하고,
    • AWS에만 존재하면 AWS 실제 KeyPair를 삭제해서 clean할 수 있을지 확인 부탁드립니다.
@powerkimhub powerkimhub added bug Something isn't working CloudDriver labels Oct 8, 2021
@dev4unet
Copy link
Member

dev4unet commented Oct 8, 2021

@powerkimhub 저 문제는 연관된 작업들이 많아서 고려해야할 부분들이 많으리라 봅니다.
다만, 크게는 VM 생성 시 cb-user 관련 부분쪽만 고려하면 될 듯싶네요.

현재 API 기반에서 자체 키 관리 기반으로 변경되면서 AWS에서 제공하지 않는 PublicKey 정보가 필수가 되었는데..
만약, 자체 관리하지 않는 키를 목록에 포함시킬 경우 cb의 경우 목록에서 상세 정보를 제공해야 하는데...
AWS에만 존재하는 키 파일에 대한 정보를 조회하기 위해 .ssh-aws 폴더에서 정보를 찾다가 정보를 조회할 파일이 없어서 목록 조회할 때 에러가 발생합니다.

키 파일을 삭제할 경우에도 키 파일의 정보를 먼저 조회하기 때문에 파일에서 Public 키의 정보를 가져오는 작업이 선행되고 있습니다.

만약, 키 정보 조회 시 .ssh-aws 폴더에 파일이 존재하지 않는 경우 에러로 예외 처리하지 않고 빈 데이터를 리턴해도 상관 없다면 전체 목록에 관리하지 않는 aws의 키를 포함할 수 있을 듯싶습니다.
대신, 저렇게될 경우 파일 에러는 무시하고 동작하므로 사용자에게 노출된 키 목록에서 CB에서 관리하지 않는 키를 선택해서 VM을 생성할 경우에는 cb-user 생성에 사용할 키 값이 없어서 원하는 형태로 동작하지 않는 VM이 생성될 수 있습니다.
이 경우 잘 못된 키를 선택했기 때문에 cb-user의 키 정보가 존재하지 않아서 해당 VM에는 후속 작업이 안되는게 맞지만...
해당 이유때문에 cb-user 기반의 작업이 동작하지 않는 다는 사실이 명시적이지는 않아서 저 부분에 대한 공지는 필요해 보입니다. (지금까지 저런 경우 버그로 리포팅되고 있어서...)

위 가정대로 동작이 가능하다면 키 파일을 삭제할 때에도 동일하게...
.ssh-aws 폴더에서 파일을 삭제할 때 삭제가 실패할 경우 예외 처리 없이 true를 리턴하도록 해야합니다.
(이 부분은 필요하다면 삭제 전에 해당 파일이 존재하는지 체크하는 로직을 추가해서 skip하는 형태로 보완은 가능하리라 봅니다.)

그럭저럭 매끄럽게 수정된다면 대략 아래처럼 바뀌어야 할 듯 싶습니다.

  • 목록에 자체 관리하지 않는 키를 포함
  • 키 정보 조회 시 .ssh-aws 폴더에 존재하지 않는 키의 경우 Private 및 Public 키 정보를 없이 전달(관리하지 않는 Key는 둘 다 공백 / 둘 중 하나의 파일이 존재 하지 않는 깨진 키는 삭제된 키 정보만 공백)
  • VM 생성 시 PublicKey가 존재하지 않는 key의 경우 에러 메시지 리턴 (예:cb에서 생성된 KEY가 아닙니다.)
  • Key 삭제시 존재 하지 않는 파일들은 Skip

그 외 다른 이슈가 있을지 모르겠지만 대충 소스 등을 살펴 봤을 때 저 부분들 위주로 수정하면 가능은 할 것같습니다.

@powerkimhub
Copy link
Member Author

@dev4unet

  • 감사합니다.
  • 생각보다 파장이 크네요.
  • 혹시, AWS 키를 아예 안쓰면 어떤가요?

@dev4unet
Copy link
Member

dev4unet commented Oct 8, 2021

@powerkimhub 음... 의도 파악이 안되는데 AWS 키를 아예 안 쓴다는게 어떤 의미인가요? ^^;;;;
현재 가장 문제가되는 부분은 VM생성 시인데 cb-user 생성에 사용되는 Public Key는 AWS가 아닌 외부에서 생성된 키도 상관 없지만 cb를 통해서 생성되지 않은 Key가 이슈라서 해결 방안이 아니기에 어차피 논외이고...
사실상 cb-user 생성에는 굳이 Public Key 방식이 아닌 리눅스 커맨드인 useradd 방식으로도 추가는 가능한....

혹시 VM 생성 시 사용되는 키를 의미하는 것이라면 VM에는 AWS에서 생성된 키만 사용 가능합니다.

@powerkimhub
Copy link
Member Author

@dev4unet

  • 혹시, driver에서 자체 생성하는 KeyPair로만 핸들링이 가능한 지를 문의드렸던 것이었습니다만,
  • AWS VM 생성 조건이 AWS에 생성한 Key 이름 설정이 필수인지요? 그러면 이 방법은 아닌거 같고요.
  • 음.. 위 삭제 flow가 쉽지 안아 보여서, 혹시 다른 방법이 없나 해서요.

@dev4unet
Copy link
Member

dev4unet commented Oct 8, 2021

@dev4unet VM 생성시PrivateKey 정보가 넘어가는게 아니라 단순히 AWS에 존재하는 키페어 이름만 전달하는 방식이라서요.
없는 키 페어 이름을 전달했을 경우 에러가 발생하는지 모르겠지만 AWS에서 관리하는 키 이름을 아무거나 하나 고정으로 사용하고 실제 사용할 cb-user에는 자체 생성한 KEY를 이용하면 사용자는 cb-user로 로그인은 가능하니 비슷한 용도로 활용은 가능하리라 봅니다.
음.. 작년인가 UI에 Key 없이 VM 생성하는 기능이 생겼었으니 KEY 없이 VM을 생성 할 수 있을 것같네요.
다만, AWS 키 없이 생성하기 때문에 cb-user 생성에 실패하면 해당 VM에 로그인 할 수 없습니다.

그리고 키 목록이 지금은 API의 리스트를 먼저 가져온 후 .ssh_aws 폴더에 파일이 없는 키들은 버리고 있습니다만..
AWS 키를 사용하지 않는다면 목록 조회를 API가 아닌 폴더나 자체 관리하는 파일에서 조회하는 방식으로 변경되어야 합니다.
자체 키 페어 관리시 PK 생성 이슈가 있어서 잠깐 언급 했었는데...
기억이 가물 거리는데 사용자 계정 별 리전 별 키페어 중복을 피해야 하는데..
보통은 AWS 계정을 2개 이상 사용하기도 하기 때문에 2개 이상의 계정에서 키페어 생성에 이슈가 없어야 해서..
현재는 파일명을 AWS가 생성한 Key의 핑거프린트 값을 이용해서 생성하고 있습니다.
그렇다 보니 자체 목록 관리 방식으로 변경되면 키 생성하고 목록쪽 로직이 변경되어야 할 듯싶네요.
아니면 별도의 목록 파일을 만들어서 처리하거나....

두 방식 모두 비슷비슷하겠지만 급하게 반영해야 한다면 소스 수정은 위에 제안드렸던 방식이 조금 더 빠를 수는 있습니다.
AWS 키를 이용하는 방식은 큰 골격의 변화는 없기 때문에 간단하게는 목록 조회 시 .ssh-aws 폴더에 존재하지 않는 키도 목록에 포함 시키고...
키 정보 조회시 .ssh-aws 폴더의 파일을 핸들링하는 부분에서 발생하는 파일처리 관련 예외 처리를 무시하면 원하는 형태로는 동작하리라 봅니다.
다만, .ssh-aws 폴더에 존재하지 않는 키로 VM을 생성할 경우에는 PublicKey 정보를 모르기에 cb-user로 로그인할 수 없습니다.
아니면 해당 키로는 아예 VM을 생성할 수 없도록 초기에 에러 메시지를 리턴하도록 하면되는데...
어떤 방식이든 이용자 측면에서는 목록에 보이는 키 중 정상적으로 생성되는 되는 키와 생성되지 않는 키가 혼재되어 있어서 혼돈의 여지가 없을까가 이슈일 것같습니다.

키 정보 조회 시 KeyValueList에 KeyType 등의 변수를 추가해서 mcb-barista나 aws 등의 값을 리턴해서 사용자가 구분 할 수 있도록은 할 수 있지만 어떨지는 모르겠네요.

그렇지 않고 AWS의 KEY API에 의존하지 않고 완전히 자체 관리형태로 간다면 AWS의 키를 사용할 수 없는 이슈는 있지만...
목록 및 VM 생성이나 키 삭제 등이 자유롭기 때문에 사용자의 혼돈도 없어서 깔끔할 듯싶습니다.
후자의 경우에는 키 생성 및 목록 조회 로직이 변경되어야 하는데 각 CSP마다 개별로 만드는 것 보다는
키 생성 관련 MakePublicKeyFromPrivateKey 공통 모듈을 제공했던 것처럼...
키 관리쪽의 생성/조회/목록의 공통 모듈을 제공해서 로직을 통일 시키는 것도 좋을 듯싶습니다.

@powerkimhub
Copy link
Member Author

@dev4unet

  • 일단, 코드 수정 작업을 들어가기 전에 좀만 더 고민을 해보는 것이 좋을 것 같습니다.
  • local에 키페어가 유지 되어야 하는 이유는 cb-user 추가를 위해서 cloud-init에 public key를 넘겨줘야 하기 때문인 게 맞는지요?
  • 그게 아니라면, local에 키페어를 유지해야 하는 부분을 좀만 더 설명해주시면 감사하겠습니다.
  • 만약, 그렇다면 혹시 AWS API를 통해서 AWS에 등록되어 있는 키의 public 키 등의 필요 정보를 얻어 오는 방법은 없을까요?

@dev4unet
Copy link
Member

dev4unet commented Oct 8, 2021

@powerkimhub 네, 로컬에 키 페어를 유지하는 이유는 cb-user 생성을 위한 PublicKey때문에 그렇습니다.
AWS API에서는 PublicKey를 조회하는 방법은 없으며 PrivateKey가 있으면 지금처럼 go 라이브러리를 이용해서 PublicKey생성이 가능하지만 AWS API로는 PrivateKey 조회는 불 가능하고 PrivateKey 정보는 키페어를 생성할 때에만 전달 받을 수 있습니다.

cb-user를 생성할 때 PublicKey가 필요하기 때문에 외부에서 전달 받아서 사용하거나 VM에 존재하는 키 파일을 리눅스 쉘 커맨드를 이용해서 복사하는 방법이 있습니다.

VM 생성 시 PublicKey를 외부에서 전달 받을 수 있으면 별도로 관리할 필요는 없지만..
지난번 cb-user 생성 정책에서 바리스타의 경우 PrivateKey와 PublicKey를 Local에 저장하고 바리스타에서 생성된 키만 사용하는 형태로 통일하는 방향으로 결정나서 local에서 관리하고 있습니다.

Local에서 관리하지 않으려면 VM 생성시에 파라메터로 PublicKey를 전달 받거나...
생성하려는 VM 이미지의 로그인 계정(예:ec2-user)을 알 수 있다면 useradd로 cb-user를 생성 후 OS 이미지에 존재하는 로그인 계정의 PublicKey파일을 생성된 cb-user에게 복사하는 형태로 cb-user 생성이 가능하기 때문에 VM 생성 요청 파라메터로 OS의 계정을 전달 받거나 PublicKey를 전달 받아야 합니다.

아니면 cb-user 이슈에서 설명 드렸던대로 "ec2-user / root / ubuntu / ..." 처럼 OS 이미지마다 사용하는 계정 정보를 바탕으로 해당 계정이 존재하면 해당 위치의 키 파일을 복사하는 형태의 스크립트를 만들어도 가능은 합니다만 cloud-init의 길이 제한이 있어서 작성 가능한 스크립트 파일의 크기가 제한되니 어느 정도 예외 처리에 제한은 있으리라 봅니다.

@powerkimhub
Copy link
Member Author

@dev4unet

  • AWS Web Console에서 cloud-init 설정을 아래처럼 실행하니 잘 적용이 되었습니다.
  • 확인 부탁드립니다.
  • AWS 적용 성공하면 Tencent, Alibaba 도 확인부탁드립니다.
#cloud-config
system_info:
  default_user:
    name: cb-user

@dev4unet
Copy link
Member

@powerkimhub
일단, 각 CSP별 콘솔에서 간단하게 테스트를 진행했습니다.
AWS 외에는 모두 실패하네요.

[AWS]
Amazon Linux 2 AMI
- cb-user 성공 / ec2-user 계정 없음
Ubuntu Server 18.04 LTS
- cb-user 성공 / ubuntu 계정 없음

[Alibaba]
Alibaba Cloud Linux 2.1903 LTS 64비트
- cb-user 실패 / root 성공
Ubuntu 18.04 64-bit
- cb-user 실패 / root 성공

[Tencent]
TencentOS Server 3.1(TK4)
- cb-user 실패 / root 성공
Ubuntu 18.04 LTS 64-bit
- cb-user 실패 / ubuntu 성공

다른 CSP들이 실패라서 일단 AWS의 소스코드는 적용하지 않았습니다.

@powerkimhub
Copy link
Member Author

@dev4unet

  • 각 웹 콘솔에서 시험하였습니다.
  • 다음 2가지 케이스를 성공하였습니다.
  • Tencent의 경우 아래 AWS처럼 하면 될것 같긴한데, 직접 시험은 못해보았습니다.
  • 아래와 같은 설정으로 가능할지 우려 되는 다른 문제는 없을 지 확인 부탁 드립니다.
  • AWS의 경우는 user(ec2-user, ubuntu) 상관 없는 위의 default_user 방법이 좋을 것 같긴 합니다.
  • 가급적, cb-user 계정을 심기 위해서 기존 KeyPair 관리 방법에 영향을(local file로 2중 관리 등) 안주었으면 합니다.

[Alibaba]

#cloud-config
users:
  - default
  - name: cb-user
    groups: sudo
    shell: /bin/bash
    sudo: ['ALL=(ALL) NOPASSWD:ALL']

runcmd:
  - cp -r /root/.ssh /home/cb-user
  - chown -R cb-user:cb-user /home/cb-user/.ssh

[AWS] user(ubuntu) 변경 대비 필요

#cloud-config
users:
  - default
  - name: cb-user
    groups: sudo
    shell: /bin/bash
    sudo: ['ALL=(ALL) NOPASSWD:ALL']

runcmd:
  - cp -r /home/ubuntu/.ssh /home/cb-user
  - chown -R cb-user:cb-user /home/cb-user/.ssh

@dev4unet
Copy link
Member

dev4unet commented Oct 12, 2021

@powerkimhub 위의 runcmd 방식이 초기에 했었던 방식인데 AWS와 Tencent처럼 OS마다 기본 계정이 다른 CSP들이 있어서 사용해야할 계정 정보를 전달 받을 수 있어야 합니다.

알리는 현재 전부 강제로 root로 되는것 같아서 cloud-init을 공통으로 사용하지 않는다면 root로 고정하면 현재로서는 문제 없을 듯싶습니다만...
텐센트는 위에 설명 드린것 처럼 TencentOS는 root 우분투는 ubuntu처럼 OS마다 계정이 다르기 때문에...
초기의 AWS처럼 사용할 OS의 계정 정보를 전달 받거나 userdata 글자 수 제한 범위 안에서 기본 계정을 찾는 로직이 구현되어야 합니다.

알리바바는 기본 유저로는 cb-user 자체가 생성이 안되지만 tencent는 cb-user과 그룹은 정상적으로 생성되는데..
기본 계정의 인증키를 읽어 들일때에는 정상적으로 읽는 것 처럼 보이는데 정작 cb-user 계정에는 0바이트의 인증키가 생성되더군요.-_-;;;
인증키 복제만 실패하고 있어서 cloud-init의 특정 기능이 추가되면 해결될지 모르겠네요..^^;;

AWS의 경우에는 default_user가 깔끔해 보이는데 바리스타를 이용해서 생성된 VM은 ec2-user 처럼 AWS에서 기본으로 가이드되는 기본 계정없이 ec2를 생성해도 무관할지에 대한 결정은 필요하리라 봅니다.

현재 AWS와 알리바바는 어느 정도 반영해도 상관 없을 듯싶은데 AWS는 default-user로 Alibaba는 root 계정에서 복사하는 형태로 키페어관리 로직들을 전부 제거하고 VM 생성에 관련 로직을 구현할까요?

@powerkimhub
Copy link
Member Author

@dev4unet

상세 현황 설명 캄사합니다.
이거 복잡하네요.

  • 다시 한번 아래 내용 검토/확인 부탁 드립니다.
  • Tencent를 포함해서 확인을 위한 추가 시험 부탁드립니다.
  • 큰문제가 없을 것 같다면,
  • 일단 이렇게 확정하고 문제 발생시 대응하면서 가면 어떨까 싶습니다.

  • 대상CSP: cloud-init 활용한 cb-user 추가 방법
  • 대상VM: Ubuntu 18.04 기준

[고려사항]

  • 가능한 CSP가 제공하는 default 계정을 유지해서, 기존 계정에 익숙한 사용자 또는 응용의 불편함을 방지
  • 키 관리와 의존성을 없애기 위해서, cb-user 설정 시 public key를 활용하지 않음
    • public key 활용을 위한 추가적인 local key 관리 삭제

[계정현황]

  • AWS/Tencent 등

    • VM default 계정이 이미지 마다 다를 수 있음.(ubuntu, ec2-user, ...)
  • Alibaba 등

    • VM default 계정이 root로 고정

[제안방법]

  • 동일한 cloud-init 스크립트를 활용
    • cloud-init 공통 스크립트 동작 개요
      • (1) cb-user 계정 추가
      • (2) root/.ssh/authorized_keys를 cb-user 계정으로 복사 후 필요시 수정
        • 수정 관련 내용: AWS root authorized_keys의 경우 다음과 같은 로그인 방지 코드가 포함됨.
        • 복사해온 authorized_keys에 관련 내용이 존재할 경우 이를 제거함.
        no-port-forwarding,no-agent-forwarding,no-X11-forwarding,command="echo 'Please login as the user \"ubuntu\" rather than the user \"root\".';echo;sleep 10;exit 142" ssh-rsa ~~~~
        

[공통 스크립트]

#cloud-config
users:
  - default
  - name: cb-user
    groups: sudo
    shell: /bin/bash
    sudo: ['ALL=(ALL) NOPASSWD:ALL']

runcmd:
  - cp -r /root/.ssh /home/cb-user
  - chown -R cb-user:cb-user /home/cb-user/.ssh
  - /bin/bash -c 'str=`cat /home/cb-user/.ssh/authorized_keys`; delimiter=ssh-rsa; s=$str$delimiter; splitStr=(); while [[ $s ]]; do splitStr+=( "${s%%"$delimiter"*}" ); s=${s#*"$delimiter"}; done; echo $delimiter${splitStr[1]} > /home/cb-user/.ssh/authorized_keys;'

[고려이슈]

  • vm stop -> start 시에 cloud-init 재실행된다면,
    • 사용자가 사용하는 동안 추가될 수 있는 /home/cb-user/.ssh/authorized_keys 파일이 초기화 될수 있음.
    • 시험해보지는 못함.
  • 그외 발생하는 이슈 등은 발생시 협의

@dev4unet
Copy link
Member

@powerkimhub 알리 클라우드는 웹 콘솔에서 테스트해 보면 정상적으로 동작하는데...

텐센트는 우분투 18.04에서 해당 스크립트를 이용하면 cb-user나 ubuntu 모두 로그인이 안되네요.
/home/ubuntu 계정은 .ssh폴더에 생성되는 인증키(authorized_keys)가 0바이트입니다.
/home/cb-user 계정은 .ssh폴더에 생성되는 인증키(authorized_keys)는 8바이트이며 "ssh-rsa"라는 내용 외에는 저장된 내용이 없네요.

@powerkimhub
Copy link
Member Author

@dev4unet

  • 확인 감사합니다.
  • Tencent가 민감하군요.
  • Tencent를 중심으로 해보도록 하겠습니다.

@dev4unet
Copy link
Member

@powerkimhub 보니까 텐센트는 /root/.ssh 폴더의 키가 0바이트네요.

@powerkimhub
Copy link
Member Author

@dev4unet

  • 정보 캄사합니다.
  • 참, 다양하네요.

@seokho-son
Copy link
Member

@powerkimhub 지금은 지원 VM 이미지을 기본 Ubuntu로 테스트하고 계시긴 할텐데..
혹시 나중에 주요 지원해야 하는 VM 이미지가 추가되면.. 다시 주요 로직이 달라져야 하는 상황이 발생할 수도 있을까요..?

@powerkimhub
Copy link
Member Author

@seokho-son

  • 배포판이 바뀐다면,
    • cb-user 계정 삽입의 경우는 다음과 같고,
    • 다른 부분에 문제가 생길지는 돌려바야 파악이 될듯 합니다.
  • cloud-init을 사용하는 CSP들의 경우 가급적 공통 스크립트(cloud-init 스크립트)를 사용하도록 할 것입니다만,
  • 특별한 CSP의 경우에 따라서는 별도의 cloud-init 스크립트를 사용할 수도 있을 것 같아요.
  • 현재 생각으로는 linux 배포판이 변경되어도
    • 동일 CSP이면서 cloud-init을 제공하는 배포판이라면 크게 문제는 없을 정도라고 생각됩니다.
    • 배포판에 영향이 생긴다면, 코드 수정이 아닌 1차 cloud-init 스크립트를 호환성 있게 수정해보면 될듯합니다.
    • 그래도 안되면, 그때 방법을 고민^^
  • cloud-init을 제공하지 않는 경우(현재 CloudIt), 표준 Shell script를 활용하고 있어 이 경우도 배포판이 바뀌면 스크립트를 조정하면 될듯합니다.
  • 윈도우OS는 다른 이슈

@powerkimhub
Copy link
Member Author

@dev4unet

  • Tencent는 cloud-init을 지원하지만,

    • user data에 shell script의 입력만을 지원하며,
    • cloud-init script를 입력하면 예기치 못한 오류가 발생하네요.
  • 그래서, shell로만 구성된 스크립트로 시험해보았습니다.

  • 그리고, cloud-init query를 이용하여 public key를 cloud-init meta 정보로 부터 획득하는 방법으로 수정하였습니다.

[다음 내용 확인 부탁드립니다.]

  • 기본은 첫번째 COMMON 스크립트로 통일시키고,
    • AWS, Alibaba 시험 성공
  • 안되는 CSP의 경우만 별도의 스크립트를 사용하는 방법으로 추진하고자 합니다.
    • 아래 두번재 Tencent용 스크립트 참고, 시험 성공

------------ COMMON: AWS/Alibaba Ubuntu 18.04 => 성공

  • common script 위치: ~/cloud-driver-libs/.cloud-init-common/cloud-init
#!/bin/bash
#### add Cloud-Barista user
useradd -s /bin/bash cb-user -rm -G sudo;
mkdir /home/cb-user/.ssh; 
curl -s `cloud-init query subplatform | sed 's/metadata (//g' | sed 's/)//g'`/latest/meta-data/public-keys/0/openssh-key > /home/cb-user/.ssh/authorized_keys;
chown -R cb-user:cb-user /home/cb-user;
echo "cb-user ALL=(ALL:ALL) NOPASSWD: ALL" >> /etc/sudoers;

------------ Tencent : Ubuntu 18.04 => 성공

  • Tencent는 cloud-init query subplatform를 제공하지 않음, Common Script를 사용할 수 없음.
  • metadata server IP를 직접 입력
#!/bin/bash
#### add Cloud-Barista user
useradd -s /bin/bash cb-user -rm -G sudo;
mkdir /home/cb-user/.ssh; 
curl -s http://169.254.0.23/latest/meta-data/public-keys/0/openssh-key > /home/cb-user/.ssh/authorized_keys;
chown -R cb-user:cb-user /home/cb-user;
echo "cb-user ALL=(ALL:ALL) NOPASSWD: ALL" >> /etc/sudoers;

@powerkimhub
Copy link
Member Author

@dev4unet

  • 추가적으로, Group 설정은 sudo만 추가하였습니다.
  • 이유는,
    • 각 CSP들이 제공하는 default user들의 소속 Group이 다 달라서,
    • 각 CSP들의 default 계정과 동일하게 맞추려면, CSP별로 스크립트가 차이가 생기고,
    • 동일 CSP 에서도 이미지에 따라 default 계정이 달라지는 경우(ec2-user, ubuntu 등)도
    • 처리가 복잡해지기 때문에 일단, sudo만 추가하고자 합니다.
    • sudo 사용 권한이 있어 별 문제는 없을 듯한데, 혹시 추후 group 권한 문제가 생기면 그때 재점검하고자 합니다.
  • AWS ubuntu 계정 예시:
    $ groups
      => ubuntu adm dialout cdrom floppy sudo audio dip video plugdev lxd netdev
    

@dev4unet
Copy link
Member

@powerkimhub 네, 텐센트를 제외하고 공통 스크립트 위쥐로 적용하고 키 페어 관리 로직을 CSP의 API 기반으로 수정하겠습니다.

@powerkimhub
Copy link
Member Author

@dev4unet

  • 캄사합니다.

@powerkimhub
Copy link
Member Author

@hyokyungk

OpenStack, IBM을 포함하여,
관련 드라이버의 다음 사항 확인 부탁드립니다.

  • cloud-init 기반 cb-user 계정 추가 공통 스크립트 작업
  • cb-user 계정 추가시 public key 제거로, Key의 local file 관리 작업 제거
  • 세부 내용은 현재 이슈에 달렸던 아래 내용 정도를 참고해주시기 바랍니다.
  • 추가 이슈 발생시 현재 이슈에 공유 부탁드립니다.

[취지]

[최종]

[기타]

@powerkimhub
Copy link
Member Author

@innodreamer

  • 관련 드라이버 중 cloud-init 사용하실 경우 확인 부탁드립니다.
  • 혹시, 오로지 cb-user 추가를 위해서 local에 key를 관리하는 경우가 있으시면,
    • 위 공통 스크립트 참고하시어 가급적 key의 local 관리는 자제해주시기 바랍니다.

@powerkimhub
Copy link
Member Author

@dev4unet @hyokyungk @innodreamer

@inno-cloudbarista
Copy link
Contributor

키관리가 없는 cloudit을 제외하고, Ibm(vpc), openstack, ms-azure를 이슈사항 관련해서 확인하였습니다.

Ibm, openstack에서 cloud-init를 이용하는데 공통 스크립트 적용 시 문제 없이 작동합니다.

azure의 경우 현재 로컬에서 sshkey를 만들어 사용하고 있는데, CSP의 sshkey 리소스를 이용하는 방법으로 변경한다면 로컬에 key를 저장하지 않고 이용 가능하다고 생각합니다.

Ibm, openstack, azure 3가지 key이중관리 제거하도록 진행하겠습니다.

@powerkimhub
Copy link
Member Author

powerkimhub commented Oct 26, 2021

[IBM 적용]

[AWS/Alibaba/Tencent 적용]

powerkimhub added a commit that referenced this issue Oct 27, 2021
Local 키페어 관리 로직 제거 (이슈 #480)
@powerkimhub powerkimhub pinned this issue Oct 27, 2021
@powerkimhub
Copy link
Member Author

powerkimhub commented Nov 1, 2021

@dev4unet @hyokyungk @inno-cloudbarista @innodreamer

[Patch 대상 및 적용 현황]

CSP Status
1. AWS 적용완료
2. Azure 적용완료
3. GCP 대상아님
4. Alibaba 적용완료
5. Tencent 적용완료
6. IBM 적용완료
7. OpenStack 적용완료
8. Cloudit 대상아님
9. NCP 적용완료 *
10. KT 적용완료

inno-cloudbarista pushed a commit to inno-cloudbarista/cb-spider that referenced this issue Nov 2, 2021
Local 키페어 관리 로직 제거  (이슈 cloud-barista#480)
- Azure SSH-key 리소스 적용 로직 추가  및 local 키페어 로직 삭제
inno-cloudbarista pushed a commit to inno-cloudbarista/cb-spider that referenced this issue Nov 2, 2021
Local 키페어 관리 로직 제거  (이슈 cloud-barista#480)
- Azure SSH-key 리소스 적용 로직 추가  및 local 키페어 로직 삭제
inno-cloudbarista pushed a commit to inno-cloudbarista/cb-spider that referenced this issue Nov 2, 2021
Local 키페어 관리 로직 제거  (이슈 cloud-barista#480)
- Azure SSH-key 리소스 적용 로직 추가  및 local 키페어 로직 삭제
inno-cloudbarista pushed a commit to inno-cloudbarista/cb-spider that referenced this issue Nov 2, 2021
Local 키페어 관리 로직 제거  (이슈 cloud-barista#480)
- Azure SSH-key 리소스 적용 로직 추가  및 local 키페어 로직 삭제
- cloud-init 스크립트 미적용 CSP
inno-cloudbarista pushed a commit to inno-cloudbarista/cb-spider that referenced this issue Nov 2, 2021
Local 키페어 관리 로직 제거  (이슈 cloud-barista#480)
- Azure SSH-key 리소스 적용 로직 추가  및 local 키페어 로직 삭제
- cloud-init 스크립트 미적용 CSP
inno-cloudbarista pushed a commit to inno-cloudbarista/cb-spider that referenced this issue Nov 3, 2021
Local 키페어 관리 로직 제거  (이슈 cloud-barista#480)
- Azure SSH-key 리소스 적용 로직 추가  및 local 키페어 로직 삭제
- cloud-init 스크립트 미적용 CSP
powerkimhub added a commit that referenced this issue Nov 3, 2021
[Azure] - Local 키페어 관리 로직 제거 (이슈 #480)
@powerkimhub powerkimhub reopened this Nov 4, 2021
inno-cloudbarista pushed a commit to inno-cloudbarista/cb-spider that referenced this issue Nov 8, 2021
- Openstack keypair 관리 로직 개선
    > 생성 및 삭제 시 리소스 존재 유무 체크 및 에러 메세지 구체화
- cloud-init 스크립트 
    > 공통 cloud-init 사용 불가 : subflatform 기능 미제공
powerkimhub added a commit that referenced this issue Nov 8, 2021
[openstack] - 키페어 관리 로직 개선 (이슈 #480)
@innodreamer
Copy link
Member

@powerkimhub
KT Cloud의 cloud-init 방식을 보완했습니다.
VM 내 root 계정 위치의 public key를 복사해서 사용하는 방식으로 변경했고, cloud-init UserData script를 활용하여 적용했습니다.

#538
https://github.com/cloud-barista/ktcloud/pull/50

NCP는 VM을 생성하면 root password를 제공하여 기본적으로 password 로그인만 가능해서 VM 내에서 root 계정 위치에 public key가 존재하지 않고, ubuntu 등의 기타 계정이 생성되어 있지않아 public key가 없어서 우선은 기존 방식(public key를 생성해서 VM에 적용하는 방식)을 cloud-init UserData script로 반영하는 방식으로 보완했습니다.

위의 내용은 아래의 표에 반영했습니다.
https://github.com/cloud-barista/cb-spider/wiki/CB-Spider-VM-User-Guide

@powerkimhub
Copy link
Member Author

[KT/NCP 적용]

@powerkimhub powerkimhub unpinned this issue Nov 22, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working CloudDriver
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants