IT Note/Cloud

Openshift ServiceAccount & S2I basic

GRuuuuu 2020. 6. 28. 22:29

원문 : 호롤리한하루/Openshift ServiceAccount & S2I basic

Overview

프로젝트의 서비스어카운트와 S2I빌드에 대해 간략하게 기술하겠습니다.

Prerequisites

Openshift v4이상 클러스터

1. Service Account

이전 문서에서는 유저가 클러스터의 리소스를 관리하기 위한 권한을 어떻게 부여받는지에대해서 설명했었습니다.

하지만 유저외에도 클러스터의 리소스를 관리해야할 경우가 생길 수 있습니다. 예를 들어 pod을 생성/삭제할 권한이 필요한 replication controller, 모니터링을 위한 외부 application 등을 생각해볼 수 있겠죠.

그래서 각 프로젝트마다 openshift API에 접근할 수 있는 권한이 필요합니다. 이걸 Service Account라고 부릅니다.

Service Account의 Source Code Control종류는 다음과 같습니다.

SCC	Description
anyuid	root를 포함한 모든 user로 컨테이너를 실행가능
hostaccess	제한된 user권한으로 호스트의 파일시스템 및 네트워크 접근 가능
hostmount-anyuid	anyuid의 host mounts를 통한 호스트 파일시스템 접근 가능
hostnetwork	호스트의 네트워크, 포트 접근 가능
node-exporter	Prometheus의 node exporter를 위한 권한
nonroot	root를 제외한 모든 user로 컨테이너 실행가능
privileged	cluster administration만을 위한 권한, 호스트의 모든 기능에 접근 가능
restricted	모든 호스트 기능에 접속 불가(Default)

1.1 프로젝트 생성 후 SCC변경해보기

실제로 프로젝트를 생성 해보고 해당 프로젝트의 SCC를 변경해보는 작업을 해보겠습니다.
예시로 사용할 app은 gitlab입니다.

일반 유저로 로그인후, 새로운 프로젝트 생성

# 유저 b로 로그인
$ oc login -u b -p abc123

# 새로운 프로젝트 생성 
$ oc new-project mygitlab

다음, 도커허브에서 gitlab이미지를 가져와서 프로젝트에 배포해주겠습니다.
새로운 app을 배포할 때에는 new-app커맨드를 사용합니다.

$ oc new-app gitlab/gitlab-ce

배포한 pod을 확인해보면 에러가 난것을 확인가능합니다.

$ oc get pod

CrashLoopBackOff 에러가 발생했습니다.

로그를 확인 :

$ oc logs gitlab-ce-1-9wd29

Permission error가 발생했습니다. 이유는 gitlab의 서비스어카운트가 적절한 권한을 받지 못했기 때문입니다.

클러스터 관리자 권한으로 로그인해서 해당 프로젝트(mygitlab)의 서비스어카운트에 anyuid권한을 부여해주도록 하겠습니다.

$ oc login -u a -p abc123


$ oc adm policy add-scc-to-user anyuid system:serviceaccount:mygitlab:default

securitycontextconstraints.security.openshift.io/anyuid added to: ["system:serviceaccount:mygitlab:default"]

다시 일반유저로 돌아와서,

$ oc login -u b -p abc123

gitlab deployment를 재시작해줍니다.

$ oc rollout latest dc/gitlab-ce -n mygitlab-xx

deploymentconfig.apps.openshift.io/gitlab-ce rolled out

그리고나서 확인해보면 제대로 pod이 뜬 것을 확인할 수 있습니다.

$ oc get pod

배포된 pod안으로 가서 권한을 확인해보면 :

$ oc rsh dc/gitlab-ce

연결된 계정이 root라는 것을 확인할 수 있습니다.

배포한 pod을 웹gui로 확인하려면, 서비스를 라우트로 개방시켜줘야합니다.

$ oc get svc

# 컨테이너의 80포트로 라우트 개방
$ oc expose service gitlab-ce --port 80

route.route.openshift.io/gitlab-ce exposed

라우트 확인:

$ oc get route

라우트에 적힌 주소로 이동해보면 gitlab의 웹화면을 확인하실 수 있습니다.

Clean up

프로젝트에 부여한 SCC를 삭제하기 위해서는 remove-scc-from-user커맨드를 사용합니다.

$ oc adm policy remove-scc-from-user anyuid system:serviceaccount:mygitlab:default
securitycontextconstraints.security.openshift.io/anyuid removed from: ["system:serviceaccount:mygitlab:default"]

2. Build

Openshift에서의 빌드방식은 크게 두가지 방식을 사용합니다.

Docker Build : 일반적인 docker build
S2I(Source-to-Image) : Openshift에서 제공하는 builder이미지를 통해 소스->이미지로 빌드 가능

docker build는 Dockerfile을 통해 이미지를 빌드하는 일반적인 방식이라 이 포스팅에서는 다루지 않겠습니다.

S2I는 아래와 같은 스텝을 통해 빌드를 진행할 수 있습니다.

application 소스 다운로드
builder이미지 다운로드
builder컨테이너에서 application 소스 빌드
빌드된 이미지는 registry에 저장
registry에서 openshift 클러스터로 배포

2.1 S2I 빌드 (in GUI)

Openshift GUI화면에서 S2I빌드를 해보도록 하겠습니다.

먼저 gui화면으로 이동해주시고, 왼쪽상단에 있는 옵션을 Developer로 바꿔주겠습니다.

그 다음 create project 선택해서 프로젝트를 새로 만들어줍니다.

프로젝트를 생성하고나면 아래와 같은 화면을 확인하실 수 있습니다.

이 페이지는 Openshift에서 app을 배포할 때 사용하는 여러가지 방법들입니다.
이 중 S2I빌드를 하려면 From Catalog를 선택해줍니다.

여기서는 배포할 application을 빌드해줄 이미지를 고르는 페이지입니다.
이번 실습에서는 샘플 php앱을 빌드해보기로하고 php이미지를 선택해줍니다.

Create Application을 하게 되면 S2I의 설정 페이지가 뜨게 됩니다.

php 버전도 설정가능하며, 빌드할 application의 소스파일도 가져올 수 있습니다.
Try Sample버튼을 눌러서 샘플 app의 소스정보를 가져오겠습니다.

이름도 정해주고, 아래로 내려가보면 Resources항목이 나옵니다. 이 항목에서는 app을 어떤방식으로 배포할 건지 고르는 부분입니다.
Deployment와 DeploymentConfig가 어떤 차이가 있는지는 다음 포스팅에서 다루도록 하겠습니다.
아무거나 고르셔도 상관없습니다.