검색

5.2. 서비스 계정을 사용하여 보안 제공

download PDF

서비스 계정을 사용하여 Git 리포지토리 및 컨테이너 리포지토리를 통한 인증에 대한 시크릿을 제공할 수 있습니다.

시크릿을 서비스 계정과 연결할 수 있습니다. 시크릿의 정보는 이 서비스 계정에서 실행되는 작업에 사용할 수 있습니다.

5.2.1. 서비스 계정의 보안 유형 및 주석

서비스 계정을 사용하여 인증 보안을 제공하는 경우 OpenShift Pipelines는 여러 가지 보안 유형을 지원합니다. 이러한 보안 유형의 대부분은 인증 보안이 유효한 리포지토리를 정의하는 주석을 제공해야 합니다.

5.2.1.1. Git 인증 보안

서비스 계정을 사용하여 인증 보안을 제공하는 경우 OpenShift Pipelines는 Git 인증에 대해 다음 유형의 보안을 지원합니다.

  • kubernetes.io/basic-auth: 기본 인증을 위한 사용자 이름과 암호
  • kubernetes.io/ssh-auth: SSH 기반 인증을 위한 키

서비스 계정을 사용하여 인증 보안을 제공하는 경우 Git 시크릿에 하나 이상의 주석 키가 있어야 합니다. 각 키의 이름은 tekton.dev/git- 로 시작해야 하며 값은 OpenShift Pipelines에서 시크릿의 인증 정보를 사용해야 하는 호스트의 URL입니다.

다음 예에서 OpenShift Pipelines는 basic-auth 시크릿을 사용하여 github.comgitlab.com 의 리포지토리에 액세스합니다.

예: 여러 Git 리포지토리를 사용한 기본 인증을 위한 인증 정보

apiVersion: v1
kind: Secret
metadata:
  name: git-secret-basic
  annotations:
    tekton.dev/git-0: github.com
    tekton.dev/git-1: gitlab.com
type: kubernetes.io/basic-auth
stringData:
  username: <username> 1
  password: <password> 2

1
리포지토리의 사용자 이름
2
리포지토리의 암호 또는 개인 액세스 토큰

다음 예와 같이 ssh-auth 시크릿을 사용하여 Git 리포지토리에 액세스하기 위한 개인 키를 제공할 수도 있습니다.

예: SSH 기반 인증을 위한 개인 키

apiVersion: v1
kind: Secret
metadata:
  name: git-secret-ssh
  annotations:
    tekton.dev/git-0: https://github.com
type: kubernetes.io/ssh-auth
stringData:
  ssh-privatekey: 1

1
SSH 개인 키 파일의 내용입니다.

5.2.1.2. 컨테이너 레지스트리 인증 보안

서비스 계정을 사용하여 인증 보안을 제공하는 경우 OpenShift Pipelines는 컨테이너(Docker) 레지스트리 인증에 대해 다음 유형의 보안을 지원합니다.

  • kubernetes.io/basic-auth: 기본 인증을 위한 사용자 이름과 암호
  • kubernetes.io/dockercfg: 직렬화된 ~/.dockercfg 파일
  • kubernetes.io/dockerconfigjson: 직렬화된 ~/.docker/config.json 파일

서비스 계정을 사용하여 인증 보안을 제공하는 경우 kubernetes.io/basic-auth 유형의 컨테이너 레지스트리 시크릿에 하나 이상의 주석 키가 있어야 합니다. 각 키의 이름은 tekton.dev/docker- 로 시작해야 하며 값은 OpenShift Pipelines에서 시크릿의 인증 정보를 사용해야 하는 호스트의 URL입니다. 이 주석은 다른 유형의 컨테이너 레지스트리 시크릿에는 필요하지 않습니다.

다음 예에서 OpenShift Pipelines는 사용자 이름과 암호를 사용하는 basic-auth 시크릿을 사용하여 quay.iomy-registry.example.com 에서 컨테이너 레지스트리에 액세스합니다.

예: 여러 컨테이너 리포지토리를 사용한 기본 인증을 위한 인증 정보

apiVersion: v1
kind: Secret
metadata:
  name: docker-secret-basic
  annotations:
    tekton.dev/docker-0: quay.io
    tekton.dev/docker-1: my-registry.example.com
type: kubernetes.io/basic-auth
stringData:
  username: <username> 1
  password: <password> 2

1
레지스트리의 사용자 이름
2
레지스트리의 암호 또는 개인 액세스 토큰

다음 예와 같이 기존 구성 파일에서 kubernetes.io/dockercfgkubernetes.io/dockerconfigjson 시크릿을 생성할 수 있습니다.

예: 기존 구성 파일에서 컨테이너 리포지토리에 인증하기 위한 시크릿을 생성하는 명령

$ oc create secret generic docker-secret-config \
    --from-file=config.json=/home/user/.docker/config.json \
    --type=kubernetes.io/dockerconfigjson

다음 예제와 같이 oc 명령줄 유틸리티를 사용하여 인증 정보에서 kubernetes.io/dockerconfigjson 시크릿을 생성할 수도 있습니다.

예: 인증 정보에서 컨테이너 리포지토리에 인증하기 위한 시크릿을 생성하는 명령

$ oc create secret docker-registry docker-secret-config \
  --docker-email=<email> \ 1
  --docker-username=<username> \ 2
  --docker-password=<password> \ 3
  --docker-server=my-registry.example.com:5000 4

1
레지스트리의 이메일 주소
2
레지스트리의 사용자 이름
3
레지스트리의 암호 또는 개인 액세스 토큰
4
레지스트리의 호스트 이름 및 포트

5.2.2. 서비스 계정을 사용하여 Git에 대한 기본 인증 구성

암호 보호 리포지토리에서 리소스를 검색하는 파이프라인의 경우 해당 파이프라인에 대한 기본 인증을 구성할 수 있습니다.

참고

기본 인증이 아닌 SSH 기반 인증을 사용하는 것이 좋습니다.

파이프라인에 대한 기본 인증을 구성하려면 기본 인증 보안을 생성하고 이 보안을 서비스 계정과 연결한 다음, 이 서비스 계정을 TaskRun 또는 PipelineRun 리소스와 연결합니다.

참고

GitHub의 경우 일반 암호를 사용한 인증은 더 이상 사용되지 않습니다. 대신 개인 액세스 토큰 을 사용합니다.

프로세스

  1. secret.yaml 파일에서 시크릿의 YAML 매니페스트를 생성합니다. 이 매니페스트에서 사용자 이름과 암호 또는 GitHub 개인 액세스 토큰 을 지정하여 대상 Git 리포지토리에 액세스합니다.

    apiVersion: v1
    kind: Secret
    metadata:
      name: basic-user-pass 1
      annotations:
        tekton.dev/git-0: https://github.com
    type: kubernetes.io/basic-auth
    stringData:
      username: <username> 2
      password: <password> 3
    1
    보안의 이름입니다. 예에서는 basic-user-pass 입니다.
    2
    Git 리포지토리의 사용자 이름입니다.
    3
    Git 리포지토리의 암호 또는 개인 액세스 토큰입니다.
  2. serviceaccount.yaml 파일에서 서비스 계정에 대한 YAML 매니페스트를 생성합니다. 이 매니페스트에서 보안을 서비스 계정과 연결합니다.

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: build-bot 1
    secrets:
      - name: basic-user-pass 2
    1
    서비스 계정의 이름입니다. 이 예에서는 build-bot 입니다.
    2
    보안의 이름입니다. 예에서는 basic-user-pass 입니다.
  3. run.yaml 파일에서 작업 실행 또는 파이프라인 실행에 대한 YAML 매니페스트를 생성하고 서비스 계정을 작업 실행 또는 파이프라인 실행과 연결합니다. 다음 예제 중 하나를 사용합니다.

    • 서비스 계정을 TaskRun 리소스와 연결합니다.

      apiVersion: tekton.dev/v1
      kind: TaskRun
      metadata:
        name: build-push-task-run-2 1
      spec:
        taskRunTemplate:
          serviceAccountName: build-bot 2
        taskRef:
          name: build-push 3
      1
      작업 실행의 이름입니다. 예에서는 build-push-task-run-2 입니다.
      2
      서비스 계정의 이름입니다. 이 예에서는 build-bot 입니다.
      3
      작업 이름입니다. 예에서는 build-push.
    • 서비스 계정을 PipelineRun 리소스와 연결합니다.

      apiVersion: tekton.dev/v1
      kind: PipelineRun
      metadata:
        name: demo-pipeline 1
        namespace: default
      spec:
        taskRunTemplate:
          serviceAccountName: build-bot 2
        pipelineRef:
          name: demo-pipeline 3
      1
      파이프라인 실행의 이름입니다. 예에서는 demo-pipeline 입니다.
      2
      서비스 계정의 이름입니다. 이 예에서는 build-bot 입니다.
      3
      파이프라인의 이름입니다. 예에서는 demo-pipeline 입니다.
  4. 다음 명령을 입력하여 생성한 YAML 매니페스트를 적용합니다.

    $ oc apply --filename secret.yaml,serviceaccount.yaml,run.yaml

5.2.3. 서비스 계정을 사용하여 Git에 대한 SSH 인증 구성

SSH 키를 사용하여 구성된 리포지토리에서 리소스를 검색하려면 파이프라인에 대한 SSH 기반 인증을 구성해야 합니다.

파이프라인에 대한 SSH 기반 인증을 구성하려면 SSH 개인 키를 사용하여 인증 시크릿을 생성하고 이 보안을 서비스 계정과 연결한 다음, 이 서비스 계정을 TaskRun 또는 PipelineRun 리소스와 연결합니다.

프로세스

  1. SSH 개인 키를 생성하거나 일반적으로 ~/.ssh/id_rsa 파일에서 사용할 수 있는 기존 개인 키를 복사합니다.
  2. secret.yaml 파일에서 시크릿의 YAML 매니페스트를 생성합니다. 이 매니페스트에서 ssh-privatekey 의 값을 SSH 개인 키 파일의 콘텐츠로 설정하고 known_hosts 값을 알려진 호스트 파일의 콘텐츠로 설정합니다.

    apiVersion: v1
    kind: Secret
    metadata:
      name: ssh-key 1
      annotations:
        tekton.dev/git-0: github.com
    type: kubernetes.io/ssh-auth
    stringData:
      ssh-privatekey: 2
      known_hosts: 3
    1
    SSH 개인 키가 포함된 시크릿의 이름입니다. 예에서는 ssh-key.
    2
    SSH 개인 키 파일의 내용입니다.
    3
    알려진 호스트 파일의 내용입니다.
    중요

    알려진 호스트 파일을 생략하면 OpenShift Pipelines에서 서버의 공개 키를 수락합니다.

  3. 선택 사항: 주석 값 끝에 :<port_number >를 추가하여 사용자 정의 SSH 포트를 지정합니다. 예: tekton.dev/git-0: github.com:2222.
  4. serviceaccount.yaml 파일에서 서비스 계정에 대한 YAML 매니페스트를 생성합니다. 이 매니페스트에서 보안을 서비스 계정과 연결합니다.

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: build-bot 1
    secrets:
      - name: ssh-key 2
    1
    서비스 계정의 이름입니다. 이 예에서는 build-bot 입니다.
    2
    SSH 개인 키가 포함된 시크릿의 이름입니다. 예에서는 ssh-key.
  5. run.yaml 파일에서 서비스 계정을 작업 실행 또는 파이프라인 실행과 연결합니다. 다음 예제 중 하나를 사용합니다.

    • 서비스 계정을 작업과 연결하려면 다음을 실행합니다.

      apiVersion: tekton.dev/v1
      kind: TaskRun
      metadata:
        name: build-push-task-run-2 1
      spec:
        taskRunTemplate:
          serviceAccountName: build-bot 2
        taskRef:
          name: build-push 3
      1
      작업 실행의 이름입니다. 예에서는 build-push-task-run-2 입니다.
      2
      서비스 계정의 이름입니다. 이 예에서는 build-bot 입니다.
      3
      작업 이름입니다. 예에서는 build-push.
    • 서비스 계정을 파이프라인과 연결하려면 다음을 실행합니다.

      apiVersion: tekton.dev/v1
      kind: PipelineRun
      metadata:
        name: demo-pipeline 1
        namespace: default
      spec:
        taskRunTemplate:
          serviceAccountName: build-bot 2
        pipelineRef:
          name: demo-pipeline 3
      1
      파이프라인 실행의 이름입니다. 예에서는 demo-pipeline 입니다.
      2
      서비스 계정의 이름입니다. 이 예에서는 build-bot 입니다.
      3
      파이프라인의 이름입니다. 예에서는 demo-pipeline 입니다.
  6. 변경 사항을 적용합니다.

    $ oc apply --filename secret.yaml,serviceaccount.yaml,run.yaml

5.2.4. 서비스 계정을 사용하여 컨테이너 레지스트리 인증 구성

레지스트리에서 컨테이너 이미지를 검색하거나 컨테이너 이미지를 레지스트리로 푸시하려면 파이프라인의 경우 해당 레지스트리에 대한 인증을 구성해야 합니다.

파이프라인에 대한 레지스트리 인증을 구성하려면 Docker 구성 파일을 사용하여 인증 보안을 생성하고 이 보안을 서비스 계정과 연결한 다음, 이 서비스 계정을 TaskRun 또는 PipelineRun 리소스와 연결합니다.

프로세스

  1. 다음 명령을 입력하여 인증 정보가 포함된 기존 config.json 파일에서 컨테이너 레지스트리 인증 보안을 생성합니다.

    $ oc create secret generic my-registry-credentials \ 1
      --from-file=config.json=/home/user/credentials/config.json 2
    1
    시크릿 이름(이 예에서는 my-registry-credentials)
    2
    config.json 파일의 경로 이름(이 예에서는 /home/user/credentials/config.json)
  2. serviceaccount.yaml 파일에서 서비스 계정에 대한 YAML 매니페스트를 생성합니다. 이 매니페스트에서 보안을 서비스 계정과 연결합니다.

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: container-bot 1
    secrets:
      - name: my-registry-credentials 2
    1
    서비스 계정의 이름입니다. 이 예에서는 container-bot 입니다.
    2
    SSH 개인 키가 포함된 시크릿의 이름입니다. 예에서는 my-registry-credentials.
  3. 작업 실행 또는 파이프라인 실행에 대한 YAML 매니페스트를 run.yaml 파일로 생성합니다. 이 파일에서 서비스 계정을 작업 실행 또는 파이프라인 실행과 연결합니다. 다음 예제 중 하나를 사용합니다.

    • 서비스 계정을 작업과 연결하려면 다음을 실행합니다.

      apiVersion: tekton.dev/v1
      kind: TaskRun
      metadata:
        name: build-container-task-run-2 1
      spec:
        taskRunTemplate:
          serviceAccountName: container-bot 2
        taskRef:
          name: build-container 3
      1
      작업 실행의 이름입니다. 예에서는 build-container-task-run-2 입니다.
      2
      서비스 계정의 이름입니다. 이 예에서는 container-bot 입니다.
      3
      작업 이름입니다. 예에서는 build-container 입니다.
    • 서비스 계정을 파이프라인과 연결하려면 다음을 실행합니다.

      apiVersion: tekton.dev/v1
      kind: PipelineRun
      metadata:
        name: demo-pipeline 1
        namespace: default
      spec:
        taskRunTemplate:
          serviceAccountName: container-bot 2
        pipelineRef:
          name: demo-pipeline 3
      1
      파이프라인 실행의 이름입니다. 예에서는 demo-pipeline 입니다.
      2
      서비스 계정의 이름입니다. 이 예에서는 container-bot 입니다.
      3
      파이프라인의 이름입니다. 예에서는 demo-pipeline 입니다.
  4. 다음 명령을 입력하여 변경 사항을 적용합니다.

    $ oc apply --filename serviceaccount.yaml,run.yaml

5.2.5. 서비스 계정을 사용한 인증에 대한 추가 고려 사항

경우에 따라 서비스 계정을 사용하여 제공하는 인증 보안을 사용하려면 추가 단계를 완료해야 합니다.

5.2.5.1. 작업의 SSH Git 인증

작업 단계에서 Git 명령을 직접 호출하고 SSH 인증을 사용할 수 있지만 추가 단계를 완료해야 합니다.

OpenShift Pipelines는 /tekton/home/.ssh 디렉터리에 SSH 파일을 제공하고 $HOME 변수를 /tekton/home 으로 설정합니다. 그러나 Git SSH 인증은 $HOME 변수를 무시하고 사용자의 /etc/passwd 파일에 지정된 홈 디렉터리를 사용합니다. 따라서 Git 명령을 사용하는 단계에서는 /tekton/home/.ssh 디렉터리를 연결된 사용자의 홈 디렉터리에 심볼릭 링크해야 합니다.

예를 들어 작업이 root 사용자로 실행되는 경우 Git 명령 앞에 다음 명령을 포함해야 합니다.

apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: example-git-task
spec:
  steps:
    - name: example-git-step
#     ...
      script:
        ln -s $HOME/.ssh /root/.ssh
#     ...

그러나 git 유형 또는 Tekton 카탈로그에서 사용할 수 있는 git-clone 작업의 파이프라인 리소스를 사용할 때는 명시적 심볼릭 링크가 필요하지 않습니다.

git 유형 작업에서 SSH 인증을 사용하는 예로, authenticating-git-commands.yaml 을 참조하십시오.

5.2.5.2. 루트가 아닌 사용자로 시크릿 사용

다음과 같은 특정 시나리오에서 루트가 아닌 사용자로 시크릿을 사용해야 할 수 있습니다.

  • 컨테이너가 실행을 실행하는 데 사용하는 사용자 및 그룹은 플랫폼에 의해 무작위화됩니다.
  • 작업의 단계에서는 루트가 아닌 보안 컨텍스트를 정의합니다.
  • 작업은 작업의 모든 단계에 적용되는 글로벌 루트가 아닌 보안 컨텍스트를 지정합니다.

이러한 시나리오에서는 작업 실행 및 파이프라인 실행을 루트가 아닌 사용자로 실행할 때 다음 측면을 고려하십시오.

  • Git에 대한 SSH 인증을 사용하려면 사용자에게 /etc/passwd 디렉터리에 유효한 홈 디렉터리가 구성되어 있어야 합니다. 유효한 홈 디렉터리가 없는 UID를 지정하면 인증에 실패합니다.
  • SSH 인증은 $HOME 환경 변수를 무시합니다. 따라서 OpenShift Pipelines(/tekton/home)에서 루트가 아닌 사용자의 유효한 홈 디렉터리에 정의된 $HOME 디렉터리의 적절한 시크릿 파일을 심볼릭해야 합니다.

또한 루트가 아닌 보안 컨텍스트에서 SSH 인증을 구성하려면 예제의 git-clone-and-check 단계를 참조하십시오.

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.