검색

10.5. 동적 승인 구성

download PDF

이 절차에서는 동적 승인을 구성하기 위한 고급 단계를 간략하게 설명합니다. 승인 체인의 기능은 웹 후크 서버를 호출하도록 웹 후크 승인 플러그인을 구성하여 확장합니다.

웹 후크 서버는 집계 API 서버로도 구성됩니다. 그러면 다른 OpenShift Container Platform 구성 요소가 내부 인증서를 사용하여 웹 후크와 통신하고 oc 명령을 사용하여 테스트를 용이하게 합니다. 또한 웹 후크에 대한 역할 기반 액세스 제어(RBAC)를 가능하게 하고 다른 API 서버의 토큰 정보가 웹 후크에 공개되는 것을 방지합니다.

전제 조건

  • 클러스터 관리자 액세스 권한이 있는 OpenShift Container Platform 계정.
  • OpenShift Container Platform CLI(oc)가 설치됨.
  • 게시된 웹 후크 서버 컨테이너 이미지.

절차

  1. 웹 후크 서버 컨테이너 이미지를 빌드하고 이미지 레지스트리를 사용하여 클러스터에서 사용 가능하게 합니다.
  2. 로컬 CA 키 및 인증서를 작성한 다음 웹 후크 서버의 인증서 서명 요청(CSR)에 서명하는 데 사용합니다.
  3. 웹 후크 리소스에 맞는 새 프로젝트를 생성합니다.

    $ oc new-project my-webhook-namespace  1
    1
    웹 후크 서버에서 특정 이름을 기대할 수 있습니다.
  4. rbac.yaml이라는 파일에서 집계된 API 서비스의 RBAC 규칙을 정의합니다.

    apiVersion: v1
    kind: List
    items:
    
    - apiVersion: rbac.authorization.k8s.io/v1  1
      kind: ClusterRoleBinding
      metadata:
        name: auth-delegator-my-webhook-namespace
      roleRef:
        kind: ClusterRole
        apiGroup: rbac.authorization.k8s.io
        name: system:auth-delegator
      subjects:
      - kind: ServiceAccount
        namespace: my-webhook-namespace
        name: server
    
    - apiVersion: rbac.authorization.k8s.io/v1  2
      kind: ClusterRole
      metadata:
        annotations:
        name: system:openshift:online:my-webhook-server
      rules:
      - apiGroups:
        - online.openshift.io
        resources:
        - namespacereservations  3
        verbs:
        - get
        - list
        - watch
    
    - apiVersion: rbac.authorization.k8s.io/v1  4
      kind: ClusterRole
      metadata:
        name: system:openshift:online:my-webhook-requester
      rules:
      - apiGroups:
        - admission.online.openshift.io
        resources:
        - namespacereservations 5
        verbs:
        - create
    
    - apiVersion: rbac.authorization.k8s.io/v1  6
      kind: ClusterRoleBinding
      metadata:
        name: my-webhook-server-my-webhook-namespace
      roleRef:
        kind: ClusterRole
        apiGroup: rbac.authorization.k8s.io
        name: system:openshift:online:my-webhook-server
      subjects:
      - kind: ServiceAccount
        namespace: my-webhook-namespace
        name: server
    
    - apiVersion: rbac.authorization.k8s.io/v1  7
      kind: RoleBinding
      metadata:
        namespace: kube-system
        name: extension-server-authentication-reader-my-webhook-namespace
      roleRef:
        kind: Role
        apiGroup: rbac.authorization.k8s.io
        name: extension-apiserver-authentication-reader
      subjects:
      - kind: ServiceAccount
        namespace: my-webhook-namespace
        name: server
    
    - apiVersion: rbac.authorization.k8s.io/v1  8
      kind: ClusterRole
      metadata:
        name: my-cluster-role
      rules:
      - apiGroups:
        - admissionregistration.k8s.io
        resources:
        - validatingwebhookconfigurations
        - mutatingwebhookconfigurations
        verbs:
        - get
        - list
        - watch
      - apiGroups:
        - ""
        resources:
        - namespaces
        verbs:
        - get
        - list
        - watch
    
    - apiVersion: rbac.authorization.k8s.io/v1
      kind: ClusterRoleBinding
      metadata:
        name: my-cluster-role
      roleRef:
        kind: ClusterRole
        apiGroup: rbac.authorization.k8s.io
        name: my-cluster-role
      subjects:
      - kind: ServiceAccount
        namespace: my-webhook-namespace
        name: server
    1
    인증 및 권한 부여를 웹 후크 서버 API에 위임합니다.
    2
    웹 후크 서버가 클러스터 리소스에 액세스할 수 있게 합니다.
    3
    리소스를 가리킵니다. 이 예는 namespacereservations 리소스를 가리킵니다.
    4
    집계된 API 서버를 사용하여 승인 검토를 작성할 수 있습니다.
    5
    리소스를 가리킵니다. 이 예는 namespacereservations 리소스를 가리킵니다.
    6
    웹 후크 서버를 사용하여 클러스터 리소스에 액세스할 수 있습니다.
    7
    인증 종료 구성을 읽기 위한 역할 바인딩.
    8
    집계된 API 서버의 기본 클러스터 역할 및 클러스터 역할 바인딩.
  5. 해당 RBAC 규칙을 클러스터에 적용합니다.

    $ oc auth reconcile -f rbac.yaml
  6. 네임스페이스에서 웹 후크를 데몬 세트 서버로 배포하는 데 사용되는 webhook-daemonset.yaml이라는 YAML 파일을 생성합니다.

    apiVersion: apps/v1
    kind: DaemonSet
    metadata:
      namespace: my-webhook-namespace
      name: server
      labels:
        server: "true"
    spec:
      selector:
        matchLabels:
          server: "true"
      template:
        metadata:
          name: server
          labels:
            server: "true"
        spec:
          serviceAccountName: server
          containers:
          - name: my-webhook-container  1
            image: <image_registry_username>/<image_path>:<tag>  2
            imagePullPolicy: IfNotPresent
            command:
            - <container_commands>  3
            ports:
            - containerPort: 8443 4
            volumeMounts:
            - mountPath: /var/serving-cert
              name: serving-cert
            readinessProbe:
              httpGet:
                path: /healthz
                port: 8443 5
                scheme: HTTPS
          volumes:
          - name: serving-cert
            secret:
              defaultMode: 420
              secretName: server-serving-cert
    1
    웹 후크 서버에서 특정 컨테이너 이름을 기대할 수 있습니다.
    2
    웹 후크 서버 컨테이너 이미지를 가리킵니다. <image_registry_username>/<image_path>:<tag>를 적절한 값으로 바꿉니다.
    3
    웹 후크 컨테이너 실행 명령을 지정합니다. <container_commands>를 적절한 값으로 바꿉니다.
    4
    포드 내에서 대상 포트를 정의합니다. 이 예에서는 8443 포트를 사용합니다.
    5
    준비 프로브가 사용하는 포트를 지정합니다. 이 예에서는 8443 포트를 사용합니다.
  7. 데몬 세트를 배포합니다.

    $ oc apply -f webhook-daemonset.yaml
  8. webhook-secret.yaml이라는 YAML 파일 내에서 서비스 제공 인증서 서명자의 시크릿을 정의합니다.

    apiVersion: v1
    kind: Secret
    metadata:
      namespace: my-webhook-namespace
      name: server-serving-cert
    type: kubernetes.io/tls
    data:
      tls.crt: <server_certificate>  1
      tls.key: <server_key>  2
    1
    서명된 웹 후크 서버 인증서를 참조합니다. <server_certificate>를 base64 형식의 적절한 인증서로 바꿉니다.
    2
    서명된 웹 후크 서버 키를 참조합니다. <server_key>를 base64 형식의 적절한 키로 바꿉니다.
  9. 시크릿을 생성합니다.

    $ oc apply -f webhook-secret.yaml
  10. webhook-service.yaml이라는 YAML 파일 내에서 서비스 계정 및 서비스를 정의합니다.

    apiVersion: v1
    kind: List
    items:
    
    - apiVersion: v1
      kind: ServiceAccount
      metadata:
        namespace: my-webhook-namespace
        name: server
    
    - apiVersion: v1
      kind: Service
      metadata:
        namespace: my-webhook-namespace
        name: server
        annotations:
          service.beta.openshift.io/serving-cert-secret-name: server-serving-cert
      spec:
        selector:
          server: "true"
        ports:
        - port: 443  1
          targetPort: 8443  2
    1
    서비스가 청취하는 포트를 정의합니다. 이 예에서는 443 포트를 사용합니다.
    2
    서비스가 연결을 전달하는 포드 내의 대상 포트를 정의합니다. 이 예에서는 8443 포트를 사용합니다.
  11. 클러스터 내에 웹 후크 서버를 노출합니다.

    $ oc apply -f webhook-service.yaml
  12. webhook-crd.yaml이라는 파일에서 웹 후크 서버의 사용자 정의 리소스 정의를 정의합니다.

    apiVersion: apiextensions.k8s.io/v1beta1
    kind: CustomResourceDefinition
    metadata:
      name: namespacereservations.online.openshift.io  1
    spec:
      group: online.openshift.io  2
      version: v1alpha1  3
      scope: Cluster  4
      names:
        plural: namespacereservations  5
        singular: namespacereservation  6
        kind: NamespaceReservation  7
    1
    CustomResourceDefinition spec 값을 반영하고 <plural>.<group> 형식입니다. 이 예에서는 namespacereservations 리소스를 사용합니다.
    2
    REST API 그룹 이름.
    3
    REST API 버전 이름.
    4
    허용되는 값은 Namespaced 또는 Cluster입니다.
    5
    URL에 포함될 복수 이름입니다.
    6
    oc 출력에 표시되는 별칭입니다.
    7
    리소스 매니페스트에 대한 참조입니다.
  13. 사용자 정의 리소스 정의를 적용합니다.

    $ oc apply -f webhook-crd.yaml
  14. webhook-api-service.yaml이라는 파일 내에서 웹 후크 서버를 집계 API 서버로 구성합니다.

    apiVersion: apiregistration.k8s.io/v1beta1
    kind: APIService
    metadata:
      name: v1beta1.admission.online.openshift.io
    spec:
      caBundle: <ca_signing_certificate>  1
      group: admission.online.openshift.io
      groupPriorityMinimum: 1000
      versionPriority: 15
      service:
        name: server
        namespace: my-webhook-namespace
      version: v1beta1
    1
    웹 후크 서버가 사용하는 서버 인증서에 서명하는 PEM 인코딩된 CA 인증서입니다. <ca_signing_certificate>를 base64 형식의 적절한 인증서로 바꿉니다.
  15. 집계된 API 서비스를 배포합니다.

    $ oc apply -f webhook-api-service.yaml
  16. webhook-config.yaml 이라는 파일 내에 웹 후크 승인 플러그인 구성을 정의합니다. 이 예에서는 검증 승인 플러그인을 사용합니다.

    apiVersion: admissionregistration.k8s.io/v1beta1
    kind: ValidatingWebhookConfiguration
    metadata:
      name: namespacereservations.admission.online.openshift.io  1
    webhooks:
    - name: namespacereservations.admission.online.openshift.io  2
      clientConfig:
        service:  3
          namespace: default
          name: kubernetes
          path: /apis/admission.online.openshift.io/v1beta1/namespacereservations  4
        caBundle: <ca_signing_certificate>  5
      rules:
      - operations:
        - CREATE
        apiGroups:
        - project.openshift.io
        apiVersions:
        - "*"
        resources:
        - projectrequests
      - operations:
        - CREATE
        apiGroups:
        - ""
        apiVersions:
        - "*"
        resources:
        - namespaces
      failurePolicy: Fail
    1
    ValidatingWebhookConfiguration 개체의 이름입니다. 이 예에서는 namespacereservations 리소스를 사용합니다.
    2
    호출할 웹 후크의 이름입니다. 이 예에서는 namespacereservations 리소스를 사용합니다.
    3
    집계된 API를 통해 웹 후크 서버에 액세스할 수 있습니다.
    4
    승인 요청에 사용되는 웹 후크 URL입니다. 이 예에서는 namespacereservation 리소스를 사용합니다.
    5
    웹 후크 서버가 사용하는 서버 인증서에 서명하는 PEM 인코딩된 CA 인증서입니다. <ca_signing_certificate>를 base64 형식의 적절한 인증서로 바꿉니다.
  17. 웹 후크를 배포합니다.

    $ oc apply -f webhook-config.yaml
  18. 웹 후크가 예상대로 작동하는지 확인합니다. 예를 들어 특정 네임스페이스를 예약하기 위해 동적 승인을 구성한 경우 해당 네임스페이스를 생성하는 요청이 거부되고 예약되지 않은 네임스페이스를 생성하는 요청이 성공했는지 확인합니다.
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.