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

이 콘텐츠는 선택한 언어로 제공되지 않습니다.

Chapter 1. Understanding authentication at runtime

Developers building images may need to configure authentication and use secrets to handle sensitive data safely within the build process. Access to build resources is governed by role-based access control (RBAC), defined by cluster administrators to ensure only authorized users can act securely.

1.1. Build secret annotation
링크 복사

Add an annotation to a build secret to ensure the build controller reconciles on create, update, or delete events for the referenced build secret.

The following example shows the usage of an annotation with a secret: 

apiVersion: v1
data:
  .dockerconfigjson: <pull_secret>
kind: Secret
metadata:
  annotations:
    build.shipwright.io/referenced.secret: "true"
  name: secret-docker
type: kubernetes.io/dockerconfigjson

where:

<pull_secret>
Specifies the Base64-encoded pull secret used by the build.
build.shipwright.io/referenced.secret
Specifies the value of the build.shipwright.io/referenced.secret annotation.

This annotation ensures the controller ignores secret events unless the secret is explicitly referenced by a build. For example, if a secret does not include this annotation, the build controller will not reconcile when that secret changes, even if an event is triggered. Reconciling on relevant events allows the build controller to re-run build configuration validations, helping detect missing or misconfigured dependencies early.

1.2. Authentication to Git repositories
링크 복사

You can define the following types of authentication for a Git repository:

  • Basic authentication
  • Secure Shell (SSH) authentication

You can configure a Git secret with these authentication methods.

1.2.1. Basic authentication
링크 복사

Configure basic authentication credentials for a Git repository by creating a Kubernetes secret with a username and password. The following example shows a Git basic-auth secret referenced by a build: 

apiVersion: v1
kind: Secret
metadata:
  name: secret-git-basic-auth
  annotations:
    build.shipwright.io/referenced.secret: "true"
type: kubernetes.io/basic-auth
stringData:
  username: <plaintext_username>
  password: <plaintext_password>

where:

type
Specifies the Kubernetes secret type. kubernetes.io/basic-auth indicates that the secret contains credentials for basic authentication.
stringData
Specifies the username and password used for basic authentication to the Git repository referenced by the build.

1.2.2. SSH authentication
링크 복사

With Secure Shell (SSH) authentication, configure Tekton annotations to specify the hostname of the Git repository provider. For example, use github.com for GitHub or gitlab.com for GitLab.

The following example shows a Kubernetes secret configured for SSH authentication to a Git repository: 

apiVersion: v1
kind: Secret
metadata:
  name: secret-git-ssh-auth
  annotations:
    build.shipwright.io/referenced.secret: "true"
type: kubernetes.io/ssh-auth
data:
  ssh-privatekey: |
    LS0tLS1CRUdJTiBPUEVOU1NIIFBSSVZBVEUgS0VZLS0tLS0K
    ZmFrZS1zc2gta2V5LWZvci1kb2NzLW9ubHkK
    LS0tLS1FTkQgT1BFTlNTSCBQUklWQVRFIEtFWS0tLS0t

where:

type
Specifies the Kubernetes secret type. kubernetes.io/ssh-auth indicates that the secret contains SSH credentials.
ssh-privatekey
Specifies the Base64-encoded SSH private key used to authenticate to the Git repository. You can generate this value by running base64 ~/.ssh/id_rsa, where ~/.ssh/id_rsa is the default location of the SSH private key commonly used for Git authentication.

1.2.3. Usage of Git secret
링크 복사

After creating a secret in the relevant namespace, you can reference it in your Build custom resource (CR). You can configure the Git secret to use either basic authentication or Secure Shell (SSH) authentication.

The following example shows the usage of a Git secret with SSH authentication type: 

apiVersion: shipwright.io/v1beta1
kind: Build
metadata:
  name: buildah-golang-build
spec:
  source:
    git:
      url: git@gitlab.com:userjohn/newtaxi.git
      cloneSecret: secret-git-ssh-auth

The following example shows the usage of a Git secret with basic authentication type: 

apiVersion: shipwright.io/v1beta1
kind: Build
metadata:
  name: buildah-golang-build
spec:
  source:
    git:
      url: https://gitlab.com/userjohn/newtaxi.git
      cloneSecret: secret-git-basic-auth

1.3. Authentication to container registries
링크 복사

To push images to a private container registry, you must create a secret in the relevant namespace and then reference it in your Build custom resource (CR).

Prerequisites

  • You have installed the Builds for Red Hat OpenShift Operator on the OpenShift Container Platform cluster.
  • You have installed the oc CLI.

Procedure

  1. Run the following command to generate a secret object: 

    $ oc --namespace <namespace> create secret docker-registry <container_registry_secret_name> \
  --docker-server=<registry_host> \
  --docker-username=<username> \
  --docker-password=<password> \
  --docker-email=<email_address>

    where:

    <namespace>
    Specifies the namespace where you want to create the secret.
    <container_registry_secret_name>
    Specifies the name of the Secret resource that stores the container registry credentials.
    <registry_host>
    Specifies the registry URL in the format https://<registry_server>/<registry_host>.
    <username>
    Specifies the registry username.
    <password>
    Specifies the password or an access token for the container registry.
    <email_address>
    Specifies the email address associated with the container registry credentials.

  2. Run the following command to annotate the secret: 

    $ oc --namespace <namespace> annotate secrets <container_registry_secret_name> build.shipwright.io/referenced.secret='true'

    where:

    <namespace>
    Specifies the namespace in which you want to create the secret.
    <container_registry_secret_name>
    Specifies the name of the Secret resource that stores the container registry credentials.

  3. Set the value of the spec.output.pushSecret field to the secret name in your Build CR: 

    apiVersion: shipwright.io/v1beta1
kind: Build
metadata:
  name: buildah-golang-build
  # ...
  output:
    image: <path_to_image>
    pushSecret: <container_registry_secret_name>

    where

    <path_to_image>
    Specifies the location of the output image.
    <container_registry_secret_name>
    Specifies the name of the Secret resource that stores the container registry credentials.
  4. Run a build using the Build CR. The container registry credentials are verified during the image push. If authentication fails, the build does not push the image.

1.4. Role-based access control
링크 복사

By default, builds for Red Hat OpenShift installation includes the following two cluster-wide roles for using Builds objects:

  • shpwright-build-aggregate-view: Grants read access to the Builds resources, such as BuildStrategy, ClusterBuildStrategy, Build, and BuildRun. This role is aggregated into the Kubernetes view role.
  • shipwright-build-aggregate-edit: Grants write access to the Builds resources that are configured at namespace level. The build resources include BuildStrategy, Build, and BuildRun. Read access is granted to all ClusterBuildStrategy resources. This role is aggregated into the Kubernetes edit and admin roles.

Only cluster administrators have write access to the ClusterBuildStrategy resources by default. You can change this setting by creating a separate Kubernetes ClusterRole with the desired permissions and binding it to the appropriate users.

Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

Theme

© 2026 Red Hat맨 위로 이동