Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

2.6. 보안을 사용하여 Pod에 민감한 데이터 제공

일부 애플리케이션에는 개발자에게 제공하길 원하지 않는 민감한 정보(암호 및 사용자 이름 등)가 필요합니다.

관리자는 Secret 오브젝트를 사용하여 이러한 정보를 명확한 텍스트로 공개하지 않고도 제공할 수 있습니다.

2.6.1. 보안 이해
링크 복사

Secret 오브젝트 유형에서는 암호, OpenShift Container Platform 클라이언트 구성 파일, 개인 소스 리포지토리 자격 증명 등과 같은 중요한 정보를 보유하는 메커니즘을 제공합니다. 보안은 Pod에서 중요한 콘텐츠를 분리합니다. 볼륨 플러그인을 사용하여 컨테이너에 보안을 마운트하거나 시스템에서 시크릿을 사용하여 Pod 대신 작업을 수행할 수 있습니다.

주요 속성은 다음과 같습니다.

  • 보안 데이터는 정의와는 별도로 참조할 수 있습니다.
  • 보안 데이터 볼륨은 임시 파일 저장 기능(tmpfs)에 의해 지원되며 노드에 저장되지 않습니다.
  • 보안 데이터는 네임스페이스 내에서 공유할 수 있습니다.

YAML Secret 오브젝트 정의

apiVersion: v1
kind: Secret
metadata:
  name: test-secret
  namespace: my-namespace
type: Opaque
1 

data:
2 

  username: <username>
3 

  password: <password>
stringData:
4 

  hostname: myapp.mydomain.com
5

1
보안의 키 이름과 값의 구조를 나타냅니다.
2
data 필드에서 허용되는 키 형식은 Kubernetes 구분자 용어집의 DNS_SUBDOMAIN 값에 있는 지침을 충족해야 합니다.
3
data 맵의 키와 관련된 값은 base64로 인코딩되어야 합니다.
4
stringData 맵의 항목이 base64로 변환된 후 해당 항목이 자동으로 data 맵으로 이동합니다. 이 필드는 쓰기 전용이며 값은 data 필드를 통해서만 반환됩니다.
5
stringData 맵의 키와 관련된 값은 일반 텍스트 문자열로 구성됩니다.

먼저 보안을 생성한 후 해당 보안을 사용하는 Pod를 생성해야 합니다.

보안 생성 시 다음을 수행합니다.

  • 보안 데이터를 사용하여 보안 오브젝트를 생성합니다.
  • Pod 서비스 계정을 업데이트하여 보안에 대한 참조를 허용합니다.
  • 보안을 환경 변수로 사용하거나 secret 볼륨을 사용하여 파일로 사용하는 Pod를 생성합니다.

2.6.1.1. 보안 유형
링크 복사

type 필드의 값은 보안의 키 이름과 값의 구조를 나타냅니다. 유형을 사용하면 보안 오브젝트에 사용자 이름과 키를 적용할 수 있습니다. 검증을 수행하지 않으려면 기본값인 opaque 유형을 사용합니다.

보안 데이터에 특정 키 이름이 있는지 확인하기 위해 서버 측 최소 검증을 트리거하려면 다음 유형 중 하나를 지정합니다.

  • kubernetes.io/basic-auth: 기본 인증으로 사용
  • kubernetes.io/dockercfg: 이미지 풀 시크릿으로 사용
  • kubernetes.io/dockerconfigjson: 이미지 풀 시크릿으로 사용
  • kubernetes.io/service-account-token: 기존 서비스 계정 API 토큰을 얻으려면 사용
  • kubernetes.io/ssh-auth: SSH 키 인증과 함께 사용
  • kubernetes.io/tls: TLS 인증 기관과 함께 사용

검증을 수행하지 않으려면 typ: Opaque를 지정합니다. 즉 보안에서 키 이름 또는 값에 대한 규칙을 준수하도록 요청하지 않습니다. opaque 보안에는 임의의 값을 포함할 수 있는 비정형 key:value 쌍을 사용할 수 있습니다.

참고

example.com/my-secret-type과 같은 다른 임의의 유형을 지정할 수 있습니다. 이러한 유형은 서버 측에 적용되지 않지만 보안 생성자가 해당 유형의 키/값 요구 사항을 준수하도록 의도했음을 나타냅니다.

다양한 유형의 시크릿 생성 예를 보려면 시크릿을 생성하는 방법 이해 를 참조하십시오.

2.6.1.2. 보안 데이터 키
링크 복사

보안키는 DNS 하위 도메인에 있어야 합니다.

2.6.1.3. 자동 생성된 보안
링크 복사

기본적으로 OpenShift Container Platform은 각 서비스 계정에 대해 다음 시크릿을 생성합니다.

  • dockercfg 이미지 풀 시크릿

  • 서비스 계정 토큰 시크릿

    참고

    OpenShift Container Platform 4.11 이전에는 서비스 계정이 생성될 때 두 번째 서비스 계정 토큰 시크릿이 생성되었습니다. 이 서비스 계정 토큰 시크릿은 Kubernetes API에 액세스하는 데 사용되었습니다.

    OpenShift Container Platform 4.11부터 이 두 번째 서비스 계정 토큰 시크릿이 더 이상 생성되지 않습니다. 이는 LegacyServiceAccountTokenNoAutoGeneration 업스트림 Kubernetes 기능 게이트가 활성화되어 Kubernetes API에 액세스하기 위한 시크릿 기반 서비스 계정 토큰의 자동 생성을 중지하기 때문입니다.

    4.15로 업그레이드한 후 기존 서비스 계정 토큰 시크릿은 삭제되지 않고 계속 작동합니다.

OpenShift 이미지 레지스트리를 클러스터의 사용자 인증 및 권한 부여 시스템에 통합하려면 이 서비스 계정 토큰 시크릿 및 Docker 구성 이미지 가져오기 보안이 필요합니다.

그러나 ImageRegistry 기능을 활성화하지 않거나 Cluster Image Registry Operator 구성에서 통합 OpenShift 이미지 레지스트리를 비활성화하면 각 서비스 계정에 대해 이러한 시크릿이 생성되지 않습니다.

주의

자동으로 생성된 시크릿을 사용하지 마십시오. 향후 OpenShift Container Platform 릴리스에서 제거될 수 있습니다.

바인딩된 서비스 계정 토큰을 얻기 위해 예상 볼륨과 함께 워크로드가 자동으로 삽입됩니다. 워크로드에 추가 서비스 계정 토큰이 필요한 경우 워크로드 매니페스트에 예상 볼륨을 추가합니다. 바인딩된 서비스 계정 토큰은 다음과 같은 이유로 서비스 계정 토큰 시크릿보다 안전합니다.

  • 바인딩된 서비스 계정 토큰은 수명이 바인딩되어 있습니다.
  • 바인딩된 서비스 계정 토큰에는 대상자가 포함됩니다.
  • 바인딩된 서비스 계정 토큰은 Pod 또는 보안에 바인딩될 수 있으며 바인딩된 오브젝트가 제거되면 바인딩된 토큰이 무효화됩니다.

자세한 내용은 볼륨 프로젝션을 사용하여 바인딩된 서비스 계정 토큰 구성 을 참조하십시오.

읽을 수 있는 API 오브젝트에서 만료되지 않은 토큰을 보안 노출하는 경우 토큰을 얻기 위해 서비스 계정 토큰 시크릿을 수동으로 생성할 수도 있습니다. 자세한 내용은 서비스 계정 토큰 시크릿 생성 을 참조하십시오.

추가 리소스

Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 소개

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

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

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

Red Hat 문서 정보

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

Legal Notice

Theme

© 2026 Red Hat맨 위로 이동