Tweet
Tweet

Slide 1

Slide 1 text

OpenShift Managed Practice Program Workshop (OMPP SRE Workshop 2021) 1 2021/12/09 本資料は2021/12/09行われた、OpenShift を運用しているパトナー様向けの プログラム OMPP (Red Hat OpenShift Managed Practice Program) で行わ れたセッションの抜粋版です。

Slide 2

Slide 2 text

このセッションの目的 • OpenShift の構成やインストールについての Deep Dive • Ingress (OpenShift だと Route) のカスタム・ドメイン、証明書周りの Deep Dive

Slide 3

Slide 3 text

目次 3 • OpenShift Node 構成 と インストール • Kubernetes and Storage • Custom Application domain

Slide 4

Slide 4 text

OpenShift Container Platform OpenShift Node 構成 / インストール 4

Slide 5

Slide 5 text

OpenShift basic structure master Infra Node AZ2 master Infra Node AZ1 master Infra Node AZ3 Cloud Service Worker Node Worker Node Worker Node Worker Node Worker Node Worker Node master Infra Node master Infra Node master Infra Node Worker Node Worker Node Worker Node Worker Node Worker Node Worker Node On premise • Three “Master Node”s are required for HA. • “Infra Node” is technically the same as “Woker Node”. Monitoring, Logging, Local Container Registry components are allowed to be installed on “Infra Node”. “Infra Node” doesn’t require subscriptions while “Worker Node” does. Note: Low Latency ( Region 内) Data Center Low Latency All nodes are (usually) Virtual Machines Nodes could be Virtual or Physical 5

Slide 6

Slide 6 text

AWS上に展開する場合のよくある構成 master worker ( 4 Core) worker (4 Core) AZ2 master worker ( 4 Core) worker (4 Core) AZ1 master worker ( 4 Core) worker (4 Core) AZ3 • OpenShift の Master Node は、3つの Node で冗長化を構成 する (多数決で正しいデータを持っている Node を決める） • AWS の AZ (Availability Zone) それぞれに、master node を 配置する。 • リージョンの中の「独立した」「場所」が AZ [1]。 • 1つの AZが1つの DataCenter (複数の DataCenterである場 合いもある）DataCenter 間の遅延はほぼ無い (遅延は2ms ～ 1ms程度とされる[2]) • 「ap-northeast-1」リージョンであれば、 「ap-northeast- 1a」 「ap-northeast-1b」 「ap-northeast-1c」のような AZが存在する。 • リージョンは、「東京」「大阪」のようにもっと地理的に離れ た概念。 Tokyo リージョン (ap-northeast-1) [1] https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-regions-availability-zones.html [2] https://youtu.be/JIQETrFC_SQ?t=1078 AZは一般的な構成では遅延を気にしなくて良い近距離に設 置されている。 AZ(ap-northeast-1a) 6

Slide 7

Slide 7 text

IPI install apiVersion: v1 baseDomain: mydomain.work compute: - architecture: amd64 hyperthreading: Enabled name: worker platform: {} replicas: 2 controlPlane: architecture: amd64 hyperthreading: Enabled name: master platform: {} replicas: 3 metadata: creationTimestamp: null name: ocp45-aws networking: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 machineNetwork: - cidr: 10.0.0.0/16 networkType: OpenShiftSDN serviceNetwork: - 172.30.0.0/16 platform: aws: region: ap-northeast-1 publish: External pullSecret: • Typical install-config.yaml file for OpenShift install on AWS • All three nodes are deployed in different AZ in the same region (ap-northeast-1) • Specifying AWS zones is supported via compute.platform.aws.zones controlPlane.platform.aws.zones but each master node is deployed in different zones with default. compute: # compute nodes - platform {} # {} means default … controlPlane: # master nodes platform {} AWS Region ap-northeast-1 3 Master Nodes 2 Worker Nodes ap-northeast-1 (Tokyo) master worker master worker master AZ(ap-northeast-1a) result install-config.yaml 7 AZ(ap-northeast-1b) AZ(ap-northeast-1c)

Slide 8

Slide 8 text

Full Stack Automation (IPI) Pre-existing Infrastructure (UPI) Bare Metal IBM Power Systems Bare Metal OpenShiftのマルチプラットフォーム対応 ユーザーが自分で OpenShift を導入する場合でも、複数の種類のインフラのPlatform をサポート IPI (Installer Provisioned Infrastructre) 方式のインストールでは、 OpenShift が稼働する Master /Woker Node から、全てインストーラーが作 成する。 Bare Metal 環境でも、BMC (Basedboard Management Controller)等を使用 して物理サーバーを自動で構築する。 UPI (User Provisioned Infrastructre) 方式のインストールでは、 OpenShift が稼働する Master /Woker Node の OSのインストールはユー ザーが、手動で行う。それより上のレイヤーのインストールは、インストー ラーが導入する。 As of OpenShift 4.9 OpenShift で検証済みの Pltaform OpenShift Container Platform 4.x Tested Integrations (for x86_x64) - Red Hat Customer Portal Nutanix AHV も Agnostic install を サポート Red HatとNutanix、オープンハイブリッド/マルチクラウド ソリューションの提供に向けた戦略的パート ナーシップを発表 / 8

Slide 9

Slide 9 text

Platform Integration $ openshift-install explain installconfig.platform KIND: InstallConfig VERSION: v1 RESOURCE: Platform is the configuration for the specific platform upon which to perform the installation. FIELDS: aws AWS is the configuration used when installing on AWS. azure Azure is the configuration used when installing on Azure. baremetal BareMetal is the configuration used when installing on bare metal. gcp GCP is the configuration used when installing on Google Cloud Platform. ibmcloud IBMCloud is the configuration used when installing on IBM Cloud. kubevirt Kubevirt is the configuration used when installing on kubevirt. libvirt Libvirt is the configuration used when installing on libvirt. none None is the empty configuration used when installing on an unsupported platform. openstack OpenStack is the configuration used when installing on OpenStack. ovirt Ovirt is the configuration used when installing on oVirt. vsphere VSphere is the configuration used when installing on vSphere. $ apiVersion: v1 baseDomain: mydomain.work compute: - architecture: amd64 hyperthreading: Enabled name: worker platform: {} replicas: 2 controlPlane: < snip ! > networkType: OpenShiftSDN serviceNetwork: - 172.30.0.0/16 platform: aws: region: ap-northeast-1 publish: External pullSecret: ******************* install-config.yaml ・platform.aws means installer will create EC2 nodes using AWS APIs. (integrated with AWS) ・platform.none means “any platform (or platform agnostic) ” install. You need to prepare nodes before you start OenShift installer. 9 openshift-install コマンドでも explain が使える

Slide 10

Slide 10 text

Platform Integration (Vmware IPI/UPI/any platform) 10 Vmware UPI install-config.yaml sample Vmware IPI install-config.yaml sample apiVersion: v1 baseDomain: example.com compute: - hyperthreading: Enabled name: worker replicas: 0 controlPlane: hyperthreading: Enabled name: master replicas: 3 metadata: name: test platform: vsphere: vcenter: your.vcenter.server username: username password: password datacenter: datacenter defaultDatastore: datastore folder: "//vm//" fips: false pullSecret: '{"auths": ...}' sshKey: 'ssh-ed25519 AAAA...' Installing a cluster on vSphere with user-provisioned infrastructure - Installing on vSphere | Installing | OpenShift Container Platform 4.9 apiVersion: v1 baseDomain: example.com compute: - hyperthreading: Enabled name: worker replicas: 3 platform: vsphere: cpus: 2 coresPerSocket: 2 memoryMB: 8196 osDisk: diskSizeGB: 120 controlPlane: hyperthreading: Enabled name: master replicas: 3 platform: vsphere: cpus: 4 coresPerSocket: 2 memoryMB: 16384 osDisk: diskSizeGB: 120 metadata: name: cluster platform: vsphere: vcenter: your.vcenter.server username: username password: password datacenter: datacenter defaultDatastore: datastore folder: folder network: VM_Network cluster: vsphere_cluster_name apiVIP: api_vip ingressVIP: ingress_vip fips: false pullSecret: '{"auths": ...}' sshKey: 'ssh-ed25519 AAAA...' Installing a cluster on vSphere with customizations - Installing on vSphere | Installing | OpenShift Container Platform 4.9 LoadBalacer will be created inside the cluster using these VIP installer will create Core OS nodes with specified specifications Nodes CPU / Memory can’t be specified here. Because nodes are prepared by user manually. With these information, provisioning of PVs will be available through vCenter Three ways for OpenShift on VMware • IPI installation (CoreOS nodes + LB deployed by installer) • UPI installation (little integration with vCenter for PVs) • any platform / platform agnostic installation (no integration with VMWare API) With these information, provisioning nodes. PV also can be deployed after installation completion.

Slide 11

Slide 11 text

No Platform Integration piVersion: v1 baseDomain: example.com compute: - hyperthreading: Enabled name: worker replicas: 0 architecture : ppc64le controlPlane: hyperthreading: Enabled name: master replicas: 3 architecture : ppc64le metadata: name: test networking: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 networkType: OpenShiftSDN serviceNetwork: - 172.30.0.0/16 platform: none: {} fips: false pullSecret: '{"auths": ...}' sshKey: 'ssh-ed25519 AAAA...' Installing a cluster on IBM Power Systems - Installing on IBM Power Systems | Installing | OpenShift Container Platform 4.9 IBM Power System apiVersion: v1 baseDomain: example.com compute: - hyperthreading: Enabled name: worker replicas: 0 controlPlane: hyperthreading: Enabled name: master replicas: 3 metadata: name: test networking: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 networkType: OpenShiftSDN serviceNetwork: - 172.30.0.0/16 platform: none: {} fips: false pullSecret: '{"auths": ...}' sshKey: 'ssh-ed25519 AAAA...' Installing a cluster on any platform - Installing on any platform | Installing | OpenShift Container Platform 4.9 Installing a cluster on any platform 11

Slide 12

Slide 12 text

Summary of installation methods 1) IPI (Master / Woker Nodes are created by installer) 2) UPI (Master / Worker Nodes are created by user) - Platform の API と連携がある (PVの Provisioning等に使用) - Platform の API と連携が全く無い Any Platform Installation (or Platform Agnostic ) 3) Assisted Installer Installation (Tech Preview @ OCP 4.9) インターネットに接続できる環境でのみ使用できる手法 インストーラーをクラウドサービスとして提供している。 openshift-install コマンドを使用 構成は install-config.yaml で管理。 SaaS installer (console.openshift.com) Any Pltaform Install を、UPI と区別している ケースもある。UPIと Any Platform の定義の境 界は、現状では曖昧になっている。 UPI と言った時に曖昧さは残るが、Any Platform Installationと言った時には曖昧さは残らない。 12

Slide 13

Slide 13 text

VMWare IPI の ロードバランサー Master nodes Worker nodes Master nodes Worker nodes VMWare IPI UPI / Any platform installation 別途設置の Load Balancer (Haproxy等) *.apps.ocp48.example.localdomain (アプリ用のドメイン) keepalived keepalived keepalived keepalived keepalived keepalived VIP VIP api.ocp48.example.localdomain (API Serverアクセス用ドメイン) *.apps.ocp48.example.localdomain (アプリ用のドメイン) api.ocp48.example.localdomain (API Serverアクセス用ドメイン) 参考：OpenShift 4.8 を vSphere 上にIPIインストールする MCO (Machine Config Operator) automatically configures keepalived as static pod API Server Endpoint API Server Endpoint Ingrees Endpoint Ingrees Endpoint ※IPI = ロードバランサーを持っているわけではなく、現状(OCP4.9) では Vmware IPIと Baremetal の IPIのみ。

Slide 14

Slide 14 text

OpenShift Container Platform Kubernetes and Storage 14

Slide 15

Slide 15 text

Data Center Kubernetes & Storage master Infra Node AZ2 master Infra Node AZ1 master Infra Node AZ3 Case1 : no Kubernetes PV Worker Node Worker Node Worker Node Worker Node Worker Node Worker Node master Infra Node master Infra Node master Infra Node Worker Node Worker Node Worker Node Worker Node Worker Node Worker Node Case 2 : Kubernetes PV (distributed stroage in cluster) Worker Node Worker Node Worker Node Amazon RDS / Aurora (same Region) Red Hat ODF (OpenShift Data Foundation) is a distributetd storage product ※ OpenShift option TCP/IP CSI driver Pod CSI driver Pod CSI driver Pod Distributed Software Storage CSI driver Pod CSI driver Pod CSI driver Pod CSI driver Pod CSI driver Pod CSI driver Pod CSI driver Pod CSI driver Pod CSI driver Pod ODF Pod ODF Pod ODF Pod access from a container via TCP/IP (eg：NFS、ObjectStorage、 JDBC Client) Pros: simple. Cons: application developers insert everything which is usually not inserted into DB 15

Slide 16

Slide 16 text

Kubernetes & Storage master Infra Node master Infra Node master Infra Node Worker Node Worker Node Worker Node Worker Node Worker Node Worker Node Case 3: Kubernetes PV (storage outside cluster) CSI driver Pod CSI driver Pod CSI driver Pod CSI driver Pod CSI driver Pod CSI driver Pod CSI driver Pod CSI driver Pod CSI driver Pod CSI vender storage Physical connection for Data Path and Management Path (SAN / Ethernet) Storage Management Software Architecture depends on product. Some are deployed as pods in cluster others are deployed outside Kubernetes cluster Data Center Storage Management Software or 16

Slide 17

Slide 17 text

CSI and in-tree plugin AWS EBS VMware (VMDK) Hardware Vender Storage EBS CSI driver in-tree EBS Volume plugin (driver) VMware CSI Driver HW vender Provided CSI Driver in-tree Vmware plugin (driver) Storage drivers are implemented in Kubernetes core. It’s hard to maintain. It’s going to be replaced by CSI in future to separate them from Kubernetes releases. (Default is in- tree at OpenShift 4.9) Kuberentes (OpenShift) CSI Interface CSI Interface OpenShift provides this as “AWS EBS CSI Driver Operator” latest tested in-tree and CSI driver by OpenShift (x86) [1] OpenShift provides this as “VMware vSphere CSI Driver Operator” (TP at 4.9) Hardware vender provides these Operators. 17

Slide 18

Slide 18 text

Enabling Tech Preview Feature with OpenShift 「VMware vSphere CSI Driver Operator」は、OpenShift 4.9 時点で Tech Preview 機能 デフォルトではインストールされてないので、「Feature Gate」 を有効化する必要がある。 5.14.4. vSphere CSI ドライバー Operator の有効化 OpenShift Container Platform 4.9 | Red Hat Customer Portal Feature Guate 有効化前 Feature Guate 有効化後 [root@bastion openshift]# oc get pod -n openshift-cluster-csi-drivers NAME READY STATUS RESTARTS AGE vmware-vsphere-csi-driver-controller-564bc86b57-ksws8 0/9 ContainerCreating 0 52s vmware-vsphere-csi-driver-node-dx8gp 3/3 Running 0 52s vmware-vsphere-csi-driver-node-jnhsr 3/3 Running 0 52s vmware-vsphere-csi-driver-node-jsbbf 3/3 Running 0 51s vmware-vsphere-csi-driver-node-shn4b 3/3 Running 0 52s vmware-vsphere-csi-driver-node-snkjf 3/3 Running 0 51s vmware-vsphere-csi-driver-node-ttpcp 3/3 Running 0 51s vmware-vsphere-csi-driver-operator-9fb7fcc4f-885xb 1/1 Running 0 97s [root@bastion openshift]# oc get sc NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE thin (default) kubernetes.io/vsphere-volume Delete Immediate false 56d thin-csi csi.vsphere.vmware.com Delete WaitForFirstConsumer false 26m [root@bastion openshift]# [root@bastion openshift]# oc get pod -n openshift-cluster-csi-drivers [root@bastion openshift]# 関連PodがDeploy Storage Class 「thin-csi」が追加 18 一度、Feature Gate を有効化すると元に戻せず、Cluster Update 時に “This cluster should not be updated to the next minor version”と警告が出るため本番環境では使用しないよ うに、した方が良いです。 (OCP4.8時点)

Slide 19

Slide 19 text

Stateful Set and PV (Persistent Volume) Node A Node B PV Pod apiVersion: apps/v1 kind: StatefulSet metadata: name: web spec: serviceName: "nginx" replicas: 1 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: k8s.gcr.io/nginx-slim:0.8 ports: - containerPort: 80 name: web volumeMounts: - name: www mountPath: /usr/share/nginx/html volumeClaimTemplates: - metadata: name: www spec: accessModes: [ "ReadWriteOnce" ] resources: requests: storage: 1Gi Pod と PVC (PV)の関係は、Pod が移 動しても保たれる。 Pod 名: web-0 PVC 名: www-web-0 順序インデックス マニフェストで指定した名前 (metadata.name) Pod名 replicas = n にすると、PVもPod 毎に作られるので、PVも n 個 に なる。 19

Slide 20

Slide 20 text

Kuberentes : AccessMode Node Node Node Node Node RWO (ReadWriteOnce) ROX (ReadOnlyMany) RWX (ReadWriteMany) Read Read Read/Write Read/Write Read/Write In Kubernetes world, these three original AccessMode shows access permissions from Nodes (Not from Pod) apiVersion: v1 kind: PersistentVolumeClaim metadata: name: block-pvc spec: accessModes: - ReadWriteOnce volumeMode: Block resources: requests: storage: 10Gi PV and PVC supports accessModes 20

Slide 21

Slide 21 text

PV Mount と Pod PV PVC1 (accessModes: ReadWriteOnce) namespace ReadWriteOnce (RWO) Running PVは node にマウントされている ・PVCは、namespaced な resource ・両方のPodから同じPVCを参照可能 namespace ContainerCreating 片方の Node からしかアクセスできない Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 3m22s default-scheduler Successfully assigned rwo/pod3 to ocp48-h49p6-worker-l7lnn Warning FailedAttachVolume 3m22s attachdetach-controller Multi-Attach error for volume "pvc-a589bfcb-7208-4f96-ad7b-196e5d9d67f8" Volume is already used by pod(s) pod1 Warning FailedMount 79s kubelet Unable to attach or mount volumes: unmounted volumes=[myvolume], unattached volumes=[myvolume kube-api-access-p4qfp]: timed out waiting for the condition 21

Slide 22

Slide 22 text

PV Mount と Pod PV PVC1 (accessModes: ReadWriteOnce) namespace PV PVC2 (accessModes: ReadWriteOncePod) namespace Running ReadWriteOnce (RWO) ReadWriteOncePod (RWOP) Pending Running Running PVは node にマウントされている ・PVCは、namespaced な resource ・両方のPodから同じPVCを使用可 既にPVCが使用 されているので、 マウントできず Pod が Pending となる。 ※ New in Kubernetes 1.22 (Alpha) Introducing Single Pod Access Mode for PersistentVolumes | Kubernetes Node上に同じ PVCを通してアクセスする Podが存在する可能性がある場合は、 排他制御がどこかに実装されてて無い場合はファイルが破壊されるおそれがある。 22

Slide 23

Slide 23 text

Poison Pill Operator (GA@4.8) / Node Health Check Operator (TP@4.9) Remediating nodes with the Poison Pill Operator - Working with nodes | Nodes | OpenShift Container Platform 4.8 medik8s/node-healthcheck-operator: K8s Node Health Check Operator (github.com) Poison Pill Operator how it works MachineHealthCheck Controller (GA) / Node Health Check Operator (TP@4.9) • Node の健康状態を監視 • Node が Fail した場合に指定された Remediation (=CR(Custom Resource) を作成) を行う。 • 指定した数以上の Node が健康な時にだけ Remediation を行う。 Poison Pill Operator ・Node を Monitoring しているシステムから CR (Custom Resource)を通じて通知を受ける ・unhealty な Node を Rebootする。 MachineHelthCheck Controller (a part of existing OpenShift Machine API) Monitoring Notify via CR (Custom Resource) Remediation (reboot) Tech Preview or Coummuity Worker Nodes Stateful Set を使用していて Node 障害が起きた時に、Pod は別の Node に 再スケジュールできても、障害 Node が PVを離さない時がある。その場合も Reboot する事で、PVを他の Node に移す事ができる。 Existing Controller 23

Slide 24

Slide 24 text

OpenShift Container Platform Custom Application Domain 24

Slide 25

Slide 25 text

OpenShift で使用されるドメイン ・User がインストール前に決めなければいけないドメイン ・Cluster 外部からのアクセスに使われるドメイン cluster.mycompany.com *.apps.cluster.mycompany.com mycompany.com ユーザーが OpenShift クラスターを作成するために準備 ネットに公開する場合はドメインを購入する必要がある。 部分は OpenShift クラス ターインストール時にユーザーが好きな名前を 指定できる。 OpenShift が、ユーザーアプリ用のドメインをとして “*.apps” を作成する。”*.apps”の部分は変更できない。 api.cluster.mycompany.com API Server アクセス用のドメイン (kubectl が使うド メイン) “api” の部分は変更できない。 25

Slide 26

Slide 26 text

Application 用の Wildcard ドメイン名 *.apps.cluster.mycompany.com A 10.20.5.4 app1.apps.cluster.mycompany.com app2.apps.cluster.mycompany.com myapp1.apps.cluster.mycompany.com testapp.apps.cluster.mycompany.com 問い合わせ DNS Server 全て同じIP Addressが返る DNS Record Zone: mycompany.com 10.20.5.4 DNS Query 26

Slide 27

Slide 27 text

Application 用の Wildcard ドメイン名 app1.apps.cluster.mycompany.com app2.apps.cluster.mycompany.com myapp1.apps.cluster.mycompany.com test.apps.cluster.mycompany.com All go to the same IP (resolved by DNS server) OpenShift Cluster 10.20.5.4 External LoadBalancer (※1) Router Pod (HA Proxy) Router Pod (HA Proxy) 172.16.10.2 app2 app1 172.16.10.3 Rotuer Pod は、どのようにして同じ IP に来たトラフィックを見分けているの か？ Node IP Node IP ※1) With Baremetal IPI, VMWare IPI, Exnternal loadbalancer is deployed inside OpenShift Cluster by using VIP Load Balancing 27

Slide 28

Slide 28 text

HTTP Host Header … A client MUST send a Host header field in all HTTP/1.1 request messages. If the target URI includes an authority component, then a client MUST send a field-value for Host that is identical to that authority component, excluding any userinfo subcomponent and its "@“ delimiter (Section 2.7.1). If the authority component is missing or undefined for the target URI, then a client MUST send a Host header field with an empty field-value. Since the Host field-value is critical information for handling a request, a user agent SHOULD generate Host as the first header field following the request-line. … HTTP Request Header HTTP Data HTTP Request HTTP 「HOST」 Header There are many HTTP headers like “Accept”, “Accept- Encoding”, “Accept-Language”, “Cache-Control” and so on. 28

Slide 29

Slide 29 text

HTTP Request Header OpenShift Cluster 10.20.5.4 External LoadBalancer Router Pod (HA Proxy) Router Pod (HA Proxy) 172.16.10.2 app2 app1 172.16.10.3 Node IP Node IP Host:app1.apps.cluster.mycompany.com HTTP Data Host:app1.apps.cluster.mycompany.com HTTP Data HTTP Host ヘッダーの値は 常に変わらない (本当はもっとたくさんの情報が Header に詰め込まれている) HTP Client (Browser/App) Host:app1.cluster.mycompany.com HTTP Data Host:app1.cluster.mycompany.com HTTP Data HTTP Client が Host ヘッダーをセット Router Pod は、Host ヘッダーを見て、 リクエストのフォワード先を判断する Host:app1.cluster.mycompany.com HTTP Data Load Balancing L4 Level Loadbalancer (no need to look into HTTP traffic) 29

Slide 30

Slide 30 text

Route Definition & HTTP Request apiVersion: route.openshift.io/v1 kind: Route metadata: name: frontend-gnztq ownerReferences: - apiVersion: networking.k8s.io/v1 controller: true kind: Ingress name: frontend uid: 4e6c59cc-704d-4f44-b390-617d879033b6 spec: host: app1.apps.cluster.mycompany.com to: kind: Service name: app1 tls: certificate: | -----BEGIN CERTIFICATE----- [...] -----END CERTIFICATE----- insecureEdgeTerminationPolicy: Redirect key: | -----BEGIN RSA PRIVATE KEY----- [...] -----END RSA PRIVATE KEY----- termination: reencrypt Host header value Service name to forward the request Router Pod (HA Proxy) app1 Host:app1.apps.cluster.mycompany.com HTTP Data incoming HTTP request Worker Node If it’s HTTPS, Router Pod needs to decrypt HTTP request to confirm the HTTP Host header. Private Key is required to decrypt the HTTP request. refer Service name to private IP resolution by Kuberentes (※1) ※1) Correctly speaking, HA Proxy resolves a Service name in advance and has Sevrvice IPs in its configuration file. 30

Slide 31

Slide 31 text

CNAME (Canonical Name Record) standard A record www.myapp.com A 10.0.5.40 CNAME record app1.myapp.com CNAME app1.apps.cluster.mycompany.com Autoritative DNS Server for Application zone (myapp.com) Authoritative DNS Server for OpenShift Zone (mycompany.com) standard A record www.mycompany.com A 10.20.5.2 app1.apps.cluster.mycompany.com A 10.20.5.4 mycompnay.com is not managed by this DNS server 31

Slide 32

Slide 32 text

CNAME and Host Header Host:app1.myapp.com HTTP Data 10.20.5.4 External LoadBalancer app1.myapp.com CNAME app1.apps.cluster.mycompany.com app1.apps.cluster.mycompany.com A 10.20.5.4 Router Pod (HA Proxy) Authoritative DNS server for 「myapp.com」 Auhtoritative DNS server for 「mycompany.com」 apiVersion: route.openshift.io/v1 kind: Route metadata: … spec: host: app1.myapp.com to: kind: Service name: app1 tls: …[ app1.myapp.com certificate & private key] OpenShift Cluster app1 OpenShift クラスター用に用意したドメイン Application 用に用意したドメイン Route には Application 用のドメ イン (app1.myapp.com) と、その証明書等を 設定する 32

Slide 33

Slide 33 text

HTTPS の Terminate External LoadBalancer Router Pod (HA Proxy) app1 Host:app1.myapp.com HTTP Data edge termination Edge (ここで 証明書を使ってdecrypt する) HTTPS HTTP private key Cert (public key) IP/Port レベルでハンドルする ので decrypt は必要無い OpenShift Cluster encrypt Cert (public key) External LoadBalancer Router Pod (HA Proxy) app1 Host:app1.myapp.com HTTP Data reencrypt Edge (ここで 証明書を使ってdecrypt する) HTTPS HTTPS private key Cert (public key) private key Cert (public key) HTTP Header 内の情報を見て処理を 内容を変える場合は decrypt が必要 Application 側に ・decrypt のために private key ・自分が信頼できるドメインだ と証明するための証明書 が必要 通常、Secret で実装 IP/Port レベルでハンドルする ので decrypt は必要無い OpenShift Cluster encrypt Cert (public key) 33 route route

Slide 34

Slide 34 text

Route の HTTPS terminate 設定 $ oc get route httpd-ex -o yaml apiVersion: route.openshift.io/v1 kind: Route metadata: annotations: openshift.io/host.generated: "true" creationTimestamp: "2021-12-02T00:49:06Z" labels: app: httpd-ex app.kubernetes.io/component: httpd-ex app.kubernetes.io/instance: httpd-ex name: httpd-ex namespace: myapp1 resourceVersion: "378757" uid: 1bcca36f-f5ba-4a3d-b30a-ab50263127dd spec: host: httpd-ex-myapp1.apps.ocp49-aws.sandbox651.opentlc.com port: targetPort: 8080-tcp tls: termination: edge to: kind: Service name: httpd-ex weight: 100 wildcardPolicy: None Route.spec.tls.termination の設定値 edge – TLS の termination を router で行う。それ 以降のバックエンドでは HTTPが使われる。 passthrough – router は、Traffic をそのままバック エンドにフォードする。 reencrypt – router で、TLS termination をするが、 バックエンドには、再度 HTTPSでエンクリプトして フォワードする。 $ oc explain Route.spec.tls.termination KIND: Route VERSION: route.openshift.io/v1 FIELD: termination DESCRIPTION: termination indicates termination type. * edge - TLS termination is done by the router and http is used to communicate with the backend (default) * passthrough - Traffic is sent straight to the destination without the router providing TLS termination * reencrypt - TLS termination is done by the router and https is used to communicate with the backend $ 34

Slide 35

Slide 35 text

証明書の種類 CA(認証局) 例 説明 自己証明書(オレオレ証明書) 自分 自己証明書の場合は、HTTPクライアント側に、信頼できるCAとして事前に登録されている事はないので、自己証明書のCAを追加 する必要がある。HTTPクライアント側の作業が必要で、一般ユーザーへのサービス提供には不向き。 DV証明書 (Domain Validation) Let’s Encrypt AWS Certificate Manager そのドメインの保持者である事を証明できれば誰でも取得できる。有料で発行している所もあったが、最近は Let’s Encrypt 等が でてきた事により無料化が進んでいる。 そのドメインが安全なものであるかの証明にはならない。基本的に暗号化のための証明書。 簡単に発行できHTTPS=安全という誤解もあるためフィッシングや詐欺サイトなどで良く用いられる(これらのサイトは DV証明書 以外は取得のハードルが高い）有害なドメインと認定された後も、ドメインが悪用され続けるのを防ぐため、更新期間が短く設定 されている傾向がある。 ドメイン名の安全性は示さないため、企業や公的機関のWebサイトでの使用は避けられる傾向にある。 OV証明書 (Organization Validation) DigCert Cybertrust GlobalSign etc. Organaization (組織/企業) の実在の証明が行われた上で発行される証明書。 日本では、帝国データバンクなどを使って、企業の実在性が確認される。さらに企業の代表電話番号経由で、申請者に対して連絡 が取れるかを確認された後、発行される。(※組織の実在証明の確認関する詳細なプロセスは、CAにより異なる。ここの例は一 例。) 取得費用が必要で、確認が厳格(CAに依存)なため、フィッシングサイトなどでは使用されにくく、ドメイン名の安全性がある程度 担保される。一方で更新の自動化は難しい。 主に企業サイトで使用される。 EV証明書 (Extended Validation) DigCert Cybertrust GlobalSign etc. OV証明書より取得基準が厳しくなっており、 CA/Brower Forum により定義されている監査を受け条件を満たしたCAだけが発行 できる(CA毎にOIDが振られる)。ドメインの確認が厳密で、ワイルドカードのドメインには発行できない。 以前はブラウザーのアドレスバーがグリーンになり組織名(企業名)が表示されていたが、表示の内容で似たような企業を見分ける のが困難との指摘があり現在ではメジャーなブラウザでは表示を取りやめている。 取得費用は一般的に OV証明書よりも高くなる。 金融系の企業で使用される。 35

Slide 36

Slide 36 text

linkedin.com/company/red-hat youtube.com/user/RedHatVideos facebook.com/redhatinc twitter.com/RedHat 36