nekop's blog

OpenShift / JBoss / WildFly / Infinispanの中の人 http://twitter.com/nekop

OpenShiftのmaster-config.yamlやnode-config.yamlの書式

OpenShift 全部俺 Advent Calendar 2017

たとえばmaster-config.yamlをカスタマイズしたい場合にどうやって記述すればいいのかなどを調べたい場合があります。

以下に項目がさらっと書かれたドキュメントがあり、さらっと把握するのには役立ちますが、やはりyaml形式の場合にどのように書いたら良いというようなガイドはありません。

https://docs.openshift.org/3.11/install_config/master_node_configuration.html

どこを見れば良いかというとソースコードです。OpenShiftはGo言語で記述されており、yaml形式の設定ファイルはこの定義とダイレクトにマップしています。

https://github.com/openshift/origin/blob/release-3.7/pkg/cmd/server/api/v1/types.go

たとえばkubernetesMasterConfig.controllerArgumentsは以下のように定義されています。

ControllerArguments ExtendedArguments `json:"controllerArguments"`

ExtendedArgumentsはkeyがstring、valueが[]stringのmapです。

type ExtendedArguments map[string][]string

つまり記述はこんな感じになります。

kubernetesMasterConfig:
  controllerArguments:
    foo:
    - bar
    - baz
    hoge:
    - "10"

string型であるので、数値などはクオートしないといけません。

Go言語の型とyaml形式のちょっとした知識は必要となりますが、難しいものではないので、このapi/v1/types.goを参照すればよい、ということさえわかっていればすぐ調べられます。

ちなみに各コンポーネントのデフォルト値を調べたい場合はソースツリーからoptions.goというファイルをリストするとたぶんわかります。

OpenShiftのディスク利用傾向

OpenShift 全部俺 Advent Calendar 2017

OpenShiftやKubernetesではどのようにディスクが使われ、どのくらいのディスクを必要とするのでしょうか。PVを割り当てて利用する分は自明ですが、それ以外はどのようになっているでしょうか。

コンテナイメージにVolumeが定義されている場合、oc new-appはEmptyDirを割り当てるようになっています。

EmptyDirは実際にはコンテナホストのファイルシステムの以下の位置にマップされています。

/var/lib/origin/openshift.local.volumes/pods/${POD_ID}/volumes/kubernetes.io~empty-dir/${MOUNT_PATH}

実際にEmptyDirへの書き込みをやってみましょう。

$ oc new-project test-volume
$ cat <<EOF | oc new-build --dockerfile=- --to=sleep
FROM registry.access.redhat.com/rhel
RUN mkdir /testvol && chmod 777 /testvol
VOLUME /testvol
CMD tail -f /dev/null
EOF
$ oc new-app sleep

初期状態のディスクはこのような状態です。Dockerのストレージドライバはoverlay2なので、コンテナのストレージは/var/lib/docker以下となります。

$ df -H
Filesystem                             Size  Used Avail Use% Mounted on
/dev/mapper/rhel_unused--221--68-root   54G   43G   12G  80% /
$ sudo du -hs /var/lib/docker /var/lib/origin
8.6G    /var/lib/docker
8.8G    /var/lib/origin

EmptyDirに1GBのsushiを書き込んでみます。/var/lib/originにファイルが作成されました。

$ oc volume dc/sleep
deploymentconfigs/sleep
  empty directory as sleep-volume-1
    mounted at /testvol
$ oc rsh dc/sleep ls -la /testvol
total 0
drwxrwsrwx. 2 root 1000200000  6 Dec 22 04:39 .
drwxr-xr-x. 1 root root       21 Dec 22 04:39 ..
$ oc rsh dc/sleep dd if=/dev/zero of=/testvol/sushi bs=1M count=1K
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 4.07493 s, 263 MB/s
$ oc rsh dc/sleep ls -l /testvol
-rw-r--r--. 1 1000200000 1000200000 1073741824 Dec 22 04:40 sushi
$ sudo find /var/lib/origin -name sushi
/var/lib/origin/openshift.local.volumes/pods/efe5f789-e6d4-11e7-9665-001a4a40dc83/volumes/kubernetes.io~empty-dir/sleep-volume-1/sushi
$ sudo du -hs /var/lib/docker /var/lib/origin
8.6G    /var/lib/docker
9.8G    /var/lib/origin

EmptyDirの定義を消してみます。EmptyDirではなくコンテナ内のディスクに書いているので、今度は/var/lib/dockerに1GBのsushiが置かれました。

$ oc volume dc/sleep --remove --confirm
deploymentconfig "sleep" updated
$ oc volume dc/sleep
deploymentconfigs/sleep
$ oc rsh dc/sleep dd if=/dev/zero of=/testvol/sushi bs=1M count=1K
$ oc rsh dc/sleep ls -l /testvol
total 1048576
-rw-r--r--. 1 1000200000 1000200000 1073741824 Dec 22 04:52 sushi
$ sudo find /var/lib/docker -name sushi
/var/lib/docker/volumes/46ddab197dfdb73aeea844898d903b6ecfe487e8abbda4724639f77e57f20836/_data/sushi
$ sudo du -hs /var/lib/docker /var/lib/origin
9.6G    /var/lib/docker
8.8G    /var/lib/origin

また、コンテナのログもログドライバがjson-fileにしろjournaldにしろ、コンテナホスト /var のディスク領域を消費します。数十のコンテナアプリケーションがログを出力することになるので、ログの量も大量です。

コンテナはこのようにコンテナホストの/var以下のディスク領域をとにかく大量に消費するため、ディスクフル障害となりやすいので注意してください。コンテナのこれらのディスク利用量を制限する簡単な方法は今のところありません1し、コンテナがどのくらいのデータやログを出力するの事前予測も簡単ではありません。ノードリソースにもよりますが、/varには200GB+程度のディスクを割りあてるなど、余裕を持ったディスク割り当てにしておくというのが今のところ最も有効な障害の予防手段となります。


  1. OpenShiftにはvolumeConfig.localQuota.perFsGroupxfs_quotaで制限をかける仕組みがあります

OpenShiftでUID指定されているコンテナをデプロイする

OpenShift 全部俺 Advent Calendar 2017

OpenShift上で動作するコンテナにはOpenShift側で採番されたUIDが割り当てられて、そのUIDで動作します。そのため、rootや特定のUIDでファイルにアクセスしたりすることを期待しているコンテナは動作しません。

とはいえ、DockerfileでUSER指定されているふつうのコンテナを動かしたいときもあります。そんなときにはSCCのnonrootを利用します。

https://docs.openshift.org/3.11/admin_guide/manage_scc.html

このOpenShiftのSCC (Security Context Constraints)はKubernetesPSP (Pod Security Policies)のベースとなっています。何度見てもプレイステーションポータブルって読んでしまいます。

https://kubernetes.io/docs/concepts/policy/pod-security-policy/

sccのデフォルトは以下のようになっています。

$ oc get scc
NAME               PRIV      CAPS      SELINUX     RUNASUSER          FSGROUP     SUPGROUP    PRIORITY   READONLYROOTFS   VOLUMES
anyuid             false     []        MustRunAs   RunAsAny           RunAsAny    RunAsAny    10         false            [configMap downwardAPI emptyDir persistentVolumeClaim projected secret]
hostaccess         false     []        MustRunAs   MustRunAsRange     MustRunAs   RunAsAny    <none>     false            [configMap downwardAPI emptyDir hostPath persistentVolumeClaim projected secret]
hostmount-anyuid   false     []        MustRunAs   RunAsAny           RunAsAny    RunAsAny    <none>     false            [configMap downwardAPI emptyDir hostPath nfs persistentVolumeClaim projected secret]
hostnetwork        false     []        MustRunAs   MustRunAsRange     MustRunAs   MustRunAs   <none>     false            [configMap downwardAPI emptyDir persistentVolumeClaim projected secret]
nonroot            false     []        MustRunAs   MustRunAsNonRoot   RunAsAny    RunAsAny    <none>     false            [configMap downwardAPI emptyDir persistentVolumeClaim projected secret]
privileged         true      [*]       RunAsAny    RunAsAny           RunAsAny    RunAsAny    <none>     false            [*]
restricted         false     []        MustRunAs   MustRunAsRange     MustRunAs   RunAsAny    <none>     false            [configMap downwardAPI emptyDir persistentVolumeClaim projected secret]

sccには適用順があります。nonrootにはpriorityがセットされていないので、まずpriorityをセットする必要があります。

https://docs.openshift.org/3.11/architecture/additional_concepts/authorization.html#scc-prioritization

$ oc patch scc nonroot -p "priority: 2"

これで準備はOKです。まずはUSERを指定したコンテナをデプロイして、割り当てられたUIDで動作していることを確認します。

$ cat <<EOF | oc new-build --dockerfile=- --to=sleep
FROM registry.access.redhat.com/rhel
RUN useradd -u 1001 -g 0 -d / -s /sbin/nologin default
USER 1001
CMD tail -f /dev/null
EOF
$ oc new-app sleep

scc, UIDの割り当てとランタイムのUIDを確認してみます。

$ oc describe project test-nonroot | grep scc
            openshift.io/sa.scc.mcs=s0:c14,c4
            openshift.io/sa.scc.supplemental-groups=1000190000/10000
            openshift.io/sa.scc.uid-range=1000190000/10000
$ oc describe pod sleep-1-5hgvn | grep scc
        openshift.io/scc=restricted
$ oc rsh dc/sleep id
uid=1000190000 gid=0(root) groups=0(root),1000190000

USER指定の1001ではないUIDとなっています。

scc nonrootをdefaultサービスアカウントに与えて再デプロイしてみます。

$ oc adm policy add-scc-to-user nonroot -z default
$ oc rollout latest sleep
$ oc describe pod sleep-2-hhzfd | grep scc
        openshift.io/scc=nonroot
$ oc rsh dc/sleep id
uid=1001(default) gid=0(root) groups=0(root)

きちんとUIDが変更されていますね。

UIDの変更方法を紹介しましたが、基本的にはコンテナイメージガイドラインに沿って、割り当てられたUIDで動作するようコンテナを作成することが推奨されます。

https://docs.openshift.org/3.11/creating_images/guidelines.html

sccの適用は基本的にはセキュリティリスクとなりますので、利用は最小限となるようにしましょう。nonrootは比較的安全なsccですが、NFS PVへのアクセスなど、UIDがキーとなるセキュリティコントロールがあるのでやはりデフォルトのrestrictedより劣ります。また、rootが許可されるprivilegedやanyuidはセキュリティ的には最低ですので、これらが適用されるコンテナのイメージは必ず信頼されるもののみとしてください。自社できちんとメンテナンスしているもの、Red Hatなどのベンダーから正式に提供されているもの、などです。

OpenShiftのResource requestとlimit

OpenShift 全部俺 Advent Calendar 2017

最初はどのように指定したらいいかわかりづらいという質問がよくあるKubernetesのResource requestとlimitです。

https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/

Podにはこのような定義でResource request, limit (リソース要求、制限)を記述します。

resources:
  requests:
    cpu: 100m
    memory: 64Mi
  limits:
    memory: 64Mi

CPUもメモリもrequestsを記述しないと、CPUはゼロ割り当てでまったく動かなくても構わない、メモリについてはいつメモリ不足で終了されても構わない、という意味になります。そのようなアプリケーションでない限り、これらは必ず指定してください。

スケジューラはrequestsを元にスケジューリングを行います。4CPU coresのノードにrequests.cpuが4のPodを割り当てたら、あとは上記のどうでもいいPod以外はそのノードにはスケジューリングされません。このPodは4CPU使えることが保証されます。

CPUについてはlimitsを指定すると、ノードにCPUが空いていてもそれ以上は利用できない、という意味になります。指定しなければ無制限です。普通のアプリケーションにとってはCPUが空いているのに使えないというのは基本的にデメリットしかありませんので、その場合はCPUについてはlimitsを指定する必要性はありません。もちろん、limitsが必要なケースはあり、たとえばユーザがビットコインを掘ることが想定されて過度な利用を制限したいというような場合はlimits指定が必要です。空いているCPUが他のPodに利用されていても、requests.cpuが指定されているPodがCPUを使おうとすればもちろんrequests.cpu分は優先してそちらに割り当てられるので、この空いているCPU利用は他のPodで確保されているCPU利用を阻害することはありません。

メモリについてはlimitsを指定しない場合(無制限)、もしくはrequestsよりlimitsを大きく指定する場合は、requestsを超えたメモリ使用量になった瞬間から、いつでもメモリ不足のため終了されても構わない、という状態になります。この「いつでもメモリ不足のため終了されても構わない」というアプリケーションはそれほど多くはないと思いますので、メモリについては基本的にrequests/limitsは同値指定で動作に十分な量を指定することが多いと思います。メモリ利用がlimits.memoryに達した場合はPodはoom-killerに殺されます。

というわけで、基本的にはrequests.cpuとrequests.memory == limits.memoryを指定しましょう。

あとはこの記事では解説しませんが、クラスタ管理者はノード保護のためkube-reservedとかevictionは適切に設定しましょう。

https://kubernetes.io/docs/tasks/administer-cluster/out-of-resource/

OpenShiftでファイルをシングルファイルマウントで置き換える

OpenShift 全部俺 Advent Calendar 2017

OpenShiftやKubernetesではConfigMapを使ってファイルを差し替えることができます。今日はJBoss EAPのstandalone-openshift.xmlをConfigMapでカスタマイズしたいなー、と思ってやってみたらストレートに行かなかった話です。

まず普通にJBoss EAPのアプリを放り込みます。

$ oc new-project test-javaee
$ oc policy add-role-to-user view -z default
$ oc new-app eap70-basic-s2i -p APPLICATION_NAME=hello-javaee -p SOURCE_REPOSITORY_URL=https://github.com/nekop/hello-javaee -p SOURCE_REPOSITORY_REF= -p CONTEXT_DIR= -p MAVEN_MIRROR_URL=http://nexus.example.com:8081/nexus/content/groups/mirror/

JBoss EAPのコンテナイメージは/opt/eap/standalone/configuration/standalone-openshift.xmlを利用するようになっているので、まずはファイルの内容はまったく変更しないで、standalone-openshift.xmlをConfigMapに移してConfigMapのsubPath指定でvolume mountして差し替えます。

$ oc create configmap eap-config --from-file=./standalone-openshift.xml
$ oc volumes dc/hello-javaee --add --name=eap-config --configmap-name=eap-config --default-mode=0777 --mount-path=/opt/eap/standalone/configuration/standalone-openshift.xml --sub-path=standalone-openshift.xml

すると、CrashLoopしました。なんでやねん。

$ oc get pod
NAME                    READY     STATUS             RESTARTS   AGE
hello-javaee-1-build    0/1       Completed          0          1m
hello-javaee-2-deploy   1/1       Running            0          33s
hello-javaee-2-p9bcj    0/1       CrashLoopBackOff   1          31s

ログを見るとsedDevice or resource busyで失敗しているログがずらずら出ており、JBoss EAPは設定ファイルが不正で起動できません、という状態になっています。

$ oc logs -p hello-javaee-2-p9bcj
sed: cannot rename /opt/eap/standalone/configuration/sedezxomS: Device or resource busy
sed: cannot rename /opt/eap/standalone/configuration/sedjGz72R: Device or resource busy
sed: cannot rename /opt/eap/standalone/configuration/sedCDOG5Q: Device or resource busy
sed: cannot rename /opt/eap/standalone/configuration/sedBrYC5Q: Device or resource busy
sed: cannot rename /opt/eap/standalone/configuration/sedwG75aV: Device or resource busy
(省略)
07:03:43,188 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
    at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131) [wildfly-controller-2.1.18.Final-redhat-1.jar:2.1.18.Final-redhat-1]
    at org.jboss.as.server.ServerService.boot(ServerService.java:362) [wildfly-server-2.1.18.Final-redhat-1.jar:2.1.18.Final-redhat-1]
    at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:301) [wildfly-controller-2.1.18.Final-redhat-1.jar:2.1.18.Final-redhat-1]
    at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_151]
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[131,9]
Message: WFLYCTL0133: Missing required attribute(s): default-job-repository

設定ファイルの内容を変更していないのになぜこのようなエラーになるのでしょうか。

JBoss EAPのコンテナイメージは起動スクリプト環境変数の内容からさまざまな設定をstandalone-openshift.xmlsedコマンドで適用します。ログではsedコマンドがDevice or resource busyで失敗していたので、もうわかりますね。ConfigMapによるファイルの差し替えを行ったので、このファイルはマウントポイントになっています。それをsedで「置き換え」しようとしているのですが、マウントポイントであるため置き換えができず、Device or resource busyというエラーとなっています。結局書き換えられるはずの設定ファイルが書き換えられないまま不完全な状態で起動シーケンスに入ってクラッシュしていたのでした。ちなみにファイルを置き換えるのではなく、編集するのであれば成功します。あとoc debugで起動するとマウントポイントでもファイルの置き換えが可能になる挙動を確認しましたが、今回は深追いしません。

コンテナイメージ作成者は設定ファイルのテンプレートは実際の設定ファイルではなく、別のファイルにしましょう。そうすればテンプレートと出力先ファイルが同一なので置き換えられない、という今回の問題は回避できます。また、記事では触れませんでしたがオリジナルのstandalone-openshift.xmlを取り出すにも一工夫必要となります。というのも、起動したコンテナから取り出すと既に起動スクリプトが設定変更を適用した後のファイルとなってしまうため、oc debugで起動したコンテナから取得しないといけなかったり面倒でした。

というわけで、設定テンプレート元ファイルと実際の設定ファイル、同一のロケーションにするのはやめましょう、というお話でした。

JBoss EAPについてはチケットを作成しましたが、以前のバージョンとの互換性とかも気にしないといけないのですぐには解決できないんじゃないかなー、という雰囲気です。チケットに書いた通り、/opt/eap/standalone/configuration/ディレクトリをまるっとConfigMap化すると大丈夫です。

OpenShiftやKubernetesのCLIでGo templateを利用する

OpenShift 全部俺 Advent Calendar 2017

OpenShiftのocコマンドやKubernetesのkubectlコマンドの--templateオプションにGo templateを指定することによって、結果の値の一部分を抜き出したりすることができるので便利です。

たとえばsvc/docker-registryのClusterIPを抜き出したり、curlにRouteのhostnameを埋め込んだりするには以下のようにします。

$ oc get svc docker-registry --template='{{.spec.clusterIP}}'
172.30.137.165
$ curl -kv https://$(oc get route docker-registry --template='{{.spec.host}}')/v2/
{"errors":[{"code":"UNAUTHORIZED","message":"authentication required","detail":null}]}

応用するとSecretからchained server certの復元と情報表示なども一発でできます。

$ oc get secret registry-certificates -o yaml
apiVersion: v1
data:
  registry.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURpRENDQW5DZ0F3SUJBZ0lCQmpBTkJna3Foa2lHOXcwQkFRc0ZBREFtTVNRd0lnWURWUVFEREJ0dmNHVnUKYzJocFpuUXRjMmxuYm1WeVFERTFNVEl3TVRBek56VXdIaGNOTVRjeE1UTXdNRFF4T1RFM1doY05NVGt4TVRNdwpNRFF4T1RFNFdqQVpNUmN3RlFZRFZRUURFdzR4TnpJdU16QXVNVE0zTGpFMk5UQ0NBU0l3RFFZSktvWklodmNOCkFRRUJCUUFEZ2dFUEFEQ0NBUW9DZ2dFQkFObVVlVVVDN3k2Y1BINDQ5QmdHbVpFWkFsNS9ZeFN3eGFONDdLeTkKRjExSVhwWHo1YnN3N2M1VDl0OU9vcUR2SWRNZjdzS0lTUmd0MHlkL2VidmdydDNuTWRLSFZLOUtLM2lPU1hQbwptWGNLelVnd0RKbEFqK1FjWkNPYmwxWFEwZkU4NlliUFhrMy9vbDcxNVFKcWwzOUFtaFpVRENVMEFuMFpGSC9GCklpWjRlVzZwNkJEUCtzcE15U01TVEs1allmMmZFUG9QYTQzZVdQek1LVUNVa3NtODhkb2xxNVlPUWgwU0ptcUUKbmZXVkd2bnA5Z3Fld2Q5dndDQU1xSVhobFhSN2hKaVB5WElkK0ZZU1FQbjdlcHlGWExMZ3A5dU9oSGVoaUpYYQpzU2VRSWYxSTZxWGxBQ2l3MjhzZDk2d25nczlySWR1bXNrTnV5eEZoaHlvZU1oMENBd0VBQWFPQnpUQ0J5akFPCkJnTlZIUThCQWY4RUJBTUNCYUF3RXdZRFZSMGxCQXd3Q2dZSUt3WUJCUVVIQXdFd0RBWURWUjBUQVFIL0JBSXcKQURDQmxBWURWUjBSQklHTU1JR0pnaWxrYjJOclpYSXRjbVZuYVhOMGNua3RaR1ZtWVhWc2RDNWhjSEJ6TG5NegpOeTV1Wld0dmNDNXBiNEliWkc5amEyVnlMWEpsWjJsemRISjVMbVJsWm1GMWJIUXVjM1pqZ2lsa2IyTnJaWEl0CmNtVm5hWE4wY25rdVpHVm1ZWFZzZEM1emRtTXVZMngxYzNSbGNpNXNiMk5oYklJT01UY3lMak13TGpFek55NHgKTmpXSEJLd2VpYVV3RFFZSktvWklodmNOQVFFTEJRQURnZ0VCQUc2R3pKSnpXaUo0L0lPaDF3YjBsakdxekFTNwpuQTM2Uy9xemZneDlLVFNWTmZQenIrZUVoaFRwSlVuNlZGNHByVnpUTnVDaE9IMVhEVk1rYkk3cVpqcUJud3FRCitHcnB5WjJOYUMxQ2prSDZ5Tm9HSEphaGFlM1BTcUFTdUJCODZCRUJIM0RsNW1xYW5uNUdYRWRFSHBad216MXEKMG5mOFQ1NHE0ZHQxZVR5R0NWaFQzL1dkS0doY2VCR2tSYkw4dDFzSnZkMHlsTWVqWmU2aVVNaURZY1NwUlJjdgpLTkJ5NXhZb2FzUU5nbnFUQVFnRzZqYkY2c00yL0MzT2JQU2trTU1Xdjg3Y3hGbVEwcEg3UndPckplSW5zMkVHCm9zUUxNL29XamlGWWtKV2xwY1BqWDZaOWJuYUlGOTZOb1RjR2F5SjM4T3BnZ0s0Q1cvQ0tCakdVN25vPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCi0tLS0tQkVHSU4gQ0VSVElGSUNBVEUtLS0tLQpNSUlDNmpDQ0FkS2dBd0lCQWdJQkFUQU5CZ2txaGtpRzl3MEJBUXNGQURBbU1TUXdJZ1lEVlFRRERCdHZjR1Z1CmMyaHBablF0YzJsbmJtVnlRREUxTVRJd01UQXpOelV3SGhjTk1UY3hNVE13TURJMU1qVTBXaGNOTWpJeE1USTUKTURJMU1qVTFXakFtTVNRd0lnWURWUVFEREJ0dmNHVnVjMmhwWm5RdGMybG5ibVZ5UURFMU1USXdNVEF6TnpVdwpnZ0VpTUEwR0NTcUdTSWIzRFFFQkFRVUFBNElCRHdBd2dnRUtBb0lCQVFEVTNIZHA3SzVmZytGU2l6SUNYM0ZICjdpOVRqbk5LSTFreXVMbWR3UE5iOUY0dzh0dGxXUlRjTzZVdG00UzVKR3ZRZkgvSVMwclV2RkRTNXZKZUhTcTUKU2lsMlk5RVZkYlhLS3FXYVBmWTBSNnlCT2NXSHlnTlludkd6bEJHNTh1Q0xQU2hVWW1lSjYxcDl4dE5aOFdGWQpiN2dSSXQwL3o2WGV3RVFnaHBPNXBjQWVlVC8wdjBzcyt6bVM3T3NYYWZDUFJ6cVdxTVBtVE14WHd0R25janUwCm9OM1FJeWlCNCtmd0krOTFZUEJ4R1NBSEhTamNMLzlxakxiamsrRnZNMzg2UUc1NFd4SFZ1SnVrNzRmaDVML1oKK0lJOWZ5Vy9tMjIxYmpRZ2JrSHpwQjN5aVhtWXEzUTZKZ1dub0dzTFE4WGdGTnNndnVFR1RDRUpFbHRwNFFUWgpBZ01CQUFHakl6QWhNQTRHQTFVZER3RUIvd1FFQXdJQ3BEQVBCZ05WSFJNQkFmOEVCVEFEQVFIL01BMEdDU3FHClNJYjNEUUVCQ3dVQUE0SUJBUUFxMGc1cWNJRVJlYjRaQUtUYldtZTFaOTlRWXJQZHdsMTlhQUdmT2N6eDJmZWIKamFVVzNYOXdlOEt3eStCTWppQk1KdmVMVFYrTlVmeUh0S0poejVFWGFXME05ZlExcUUrUkZBWWRubnJTNFBtSwpSczhCVkJrbHM4aWVqY2NwSy82ZGNvS2U5ZmJrNE5mRTNTdEVhSVFjVEtlUnVBeC85c1pVeTVpK01GYUxJUmNZCkk3eDdFc3AvVmlxY1hBSGt6R29Mb09ZSjRHMmF3akFidENPbmVHQ3B2ZTgrWmdDVzBjak1KYWRId1Vqb1dMRUUKNWVpdVRHRUZaN3Z6RlQwbWhpZHg3K0pwOUZpT1o1NmdiNFJFQXpzWTVXZ003Z3BGNWNRWnBzOFZCNWNxQ1dUbwpNQjlHeThpdlhRUS93KzRibUpxeWFlUVozcjMxVnBrSVVaZlJ0RE9QCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0KLS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUM2akNDQWRLZ0F3SUJBZ0lCQVRBTkJna3Foa2lHOXcwQkFRc0ZBREFtTVNRd0lnWURWUVFEREJ0dmNHVnUKYzJocFpuUXRjMmxuYm1WeVFERTFNVEl3TVRBek56VXdIaGNOTVRjeE1UTXdNREkxTWpVMFdoY05Nakl4TVRJNQpNREkxTWpVMVdqQW1NU1F3SWdZRFZRUUREQnR2Y0dWdWMyaHBablF0YzJsbmJtVnlRREUxTVRJd01UQXpOelV3CmdnRWlNQTBHQ1NxR1NJYjNEUUVCQVFVQUE0SUJEd0F3Z2dFS0FvSUJBUURVM0hkcDdLNWZnK0ZTaXpJQ1gzRkgKN2k5VGpuTktJMWt5dUxtZHdQTmI5RjR3OHR0bFdSVGNPNlV0bTRTNUpHdlFmSC9JUzByVXZGRFM1dkplSFNxNQpTaWwyWTlFVmRiWEtLcVdhUGZZMFI2eUJPY1dIeWdOWW52R3psQkc1OHVDTFBTaFVZbWVKNjFwOXh0Tlo4V0ZZCmI3Z1JJdDAvejZYZXdFUWdocE81cGNBZWVULzB2MHNzK3ptUzdPc1hhZkNQUnpxV3FNUG1UTXhYd3RHbmNqdTAKb04zUUl5aUI0K2Z3SSs5MVlQQnhHU0FISFNqY0wvOXFqTGJqaytGdk0zODZRRzU0V3hIVnVKdWs3NGZoNUwvWgorSUk5ZnlXL20yMjFialFnYmtIenBCM3lpWG1ZcTNRNkpnV25vR3NMUThYZ0ZOc2d2dUVHVENFSkVsdHA0UVRaCkFnTUJBQUdqSXpBaE1BNEdBMVVkRHdFQi93UUVBd0lDcERBUEJnTlZIUk1CQWY4RUJUQURBUUgvTUEwR0NTcUcKU0liM0RRRUJDd1VBQTRJQkFRQXEwZzVxY0lFUmViNFpBS1RiV21lMVo5OVFZclBkd2wxOWFBR2ZPY3p4MmZlYgpqYVVXM1g5d2U4S3d5K0JNamlCTUp2ZUxUVitOVWZ5SHRLSmh6NUVYYVcwTTlmUTFxRStSRkFZZG5uclM0UG1LClJzOEJWQmtsczhpZWpjY3BLLzZkY29LZTlmYms0TmZFM1N0RWFJUWNUS2VSdUF4LzlzWlV5NWkrTUZhTElSY1kKSTd4N0VzcC9WaXFjWEFIa3pHb0xvT1lKNEcyYXdqQWJ0Q09uZUdDcHZlOCtaZ0NXMGNqTUphZEh3VWpvV0xFRQo1ZWl1VEdFRlo3dnpGVDBtaGlkeDcrSnA5RmlPWjU2Z2I0UkVBenNZNVdnTTdncEY1Y1FacHM4VkI1Y3FDV1RvCk1COUd5OGl2WFFRL3crNGJtSnF5YWVRWjNyMzFWcGtJVVpmUnRET1AKLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
  registry.key: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFb3dJQkFBS0NBUUVBMlpSNVJRTHZMcHc4ZmpqMEdBYVprUmtDWG45akZMREZvM2pzckwwWFhVaGVsZlBsCnV6RHR6bFAyMzA2aW9POGgweC91d29oSkdDM1RKMzk1dStDdTNlY3gwb2RVcjBvcmVJNUpjK2laZHdyTlNEQU0KbVVDUDVCeGtJNXVYVmREUjhUenBoczllVGYraVh2WGxBbXFYZjBDYUZsUU1KVFFDZlJrVWY4VWlKbmg1YnFubwpFTS82eWt6Skl4Sk1ybU5oL1o4UStnOXJqZDVZL013cFFKU1N5Ynp4MmlXcmxnNUNIUkltYW9TZDlaVWErZW4yCkNwN0IzMi9BSUF5b2hlR1ZkSHVFbUkvSmNoMzRWaEpBK2Z0Nm5JVmNzdUNuMjQ2RWQ2R0lsZHF4SjVBaC9VanEKcGVVQUtMRGJ5eDMzckNlQ3oyc2gyNmF5UTI3TEVXR0hLaDR5SFFJREFRQUJBb0lCQUdmL1pMdU12SUJkNHpnOQp4c1paR1R2V1pXQi9xUDh4d3pYd3pjZC9GbFRiQzRMSE1rNTRBNkswVlhMRkpreWdJRjNHakp2bEFuTVJMRFZiCjQvYmVYUmJwczlHNko4c2xPNFFERnE3VlJjMDFsNHRpbEJNSVhmNmRaMnZ4cWJNMS9iTTk5eTBkbnlqUEFIQTkKUGpvYWN0RTdNcXRyZnVhbFptOGU5c0pmbW9RaC9jNW5QWmptcW9LeVpUbEw5c2cwaDVKVzEwQkk0UVZ0aHNlZwpmMnVEblpveTB3R0JXTG9jbyt1MmhIckdOUmlhYVZuUnJWRDhOYXRXRFd1eVArZFpKdmlBaTFDemc3cktUcDczCjRhUklzZVlEdWp1Z1dyMDRpSGE2RGpyQlFpMm8vUHNwRGI0N3oraUtTUmIvK2haTDBoQ2RWWStERXl5eTI1WjYKbEhrMnJFRUNnWUVBNWNlSHhaN0pST3hzZDNId0xqT0lwMUZteFBNRkRwMmxwYVpwZTlaczFHVTZmaHB0SmRXYQp0ZXJPWFVVS3NCNE5mM1VtQjA5ZENzdjBlVWlIU2czL21PNnJPQ0hRREdyWGNINHN2S2pvdUFIMGc0MktsUUdYCkZBcENJdVRndGV5MXg5SDRyRnB1TWk4eGh6OGZURFJBV3lSRHJ0U0F4TjJXaGMrV0RtaUlsZkVDZ1lFQThtaVEKcnJMaFQyb3FDT0RrSTVnc3BKRkh4VW5RNUc4Y0Vpc211WEcvUWtGdUlraXJ0dVdSUE5idlRtTDN4dFl2YjUxYgpHSmZibUlnTDYvbWt0SWowVkxCeDNrWUk1dm1McklDZW1aN3Bta0E3TjBmYUFYS2R5Rkd5V3dEZG9jUjNaVTZUCnR5RWNPSCt2dHJ4WnF5bnNQRGZ6Ny9YZjdOdzg1eWhMckJ6M2d1MENnWUVBdkJhZWJ3ZlJYUmZpbWN1c2ZVVTEKNFRCaTNXakloUFJLdWRRRW1KZ25NWjFEU2lJN29qSzlsNWdESUpuNWE3ek44NzFqU2F5UFR0MHcyMjZoUDk5QgprR0FkeTY3eDdKZ3dqaWJhVy93dnN4LzJsUkR4bFpOZHBjdlg0MVJURk5nVTNPSmxtai9UNEVSOVdHWTFLbDNECktGZ0JCMFZ2dXJaZ0ZseWNTbU1MR3lFQ2dZQWFhTkg2ZG5xZGtFOXNFRFJLdkhXQXFHTk5WekZ1OGJ2NUxzSlYKU2RNd2dMaGkrOC9aYVVGZGczMG02UmxkakZBMnRNb0w3OTk0eXJtaHg5enQzazNnUENqcnNtMmQzR29mTFJRYQpZSG5LMkZ5Yk5UVEhHNW1kRFdtRkNKOGMxSzY5VnNZNUdWNWR1V3VIV1JYYjFBRnN2aHZSZE5Ra2xnbjhsU05KCmFRNStNUUtCZ0FzeTk3R0hqdjJkU0VwbGVnekhpNEE0TjdjVkFlU2s2b2U1ay9XL0lqRXE3c0QvOXhCM2p2Sy8KUDdxYnFiSkNycGVudldnbENXRkRURGNOZTVhU3lIOWplQnlXQW1venRWblIyK3FQcDhIczJ3T21mVFZHYnhmUAphanNFZ3FYNkI4ekxpcnBFWnFpbzNmUTg2UDNLOTJxbHQ1ZHBQN3k3ZXh1b0pUcHlYKzg5Ci0tLS0tRU5EIFJTQSBQUklWQVRFIEtFWS0tLS0tCg==
kind: Secret
metadata:
  creationTimestamp: 2017-11-30T04:19:21Z
  name: registry-certificates
  namespace: default
  resourceVersion: "2970757"
  selfLink: /api/v1/namespaces/default/secrets/registry-certificates
  uid: a42d3d19-d585-11e7-be6c-001a4a40dc83
type: Opaque

以下のコマンドで証明書の情報を直接を表示できます。

$ openssl crl2pkcs7 -nocrl -certfile <(oc get secret registry-certificates --template='{{index .data "registry.crt"}}' | base64 -d) | openssl pkcs7 -print_certs -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 6 (0x6)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=openshift-signer@1512010375
        Validity
            Not Before: Nov 30 04:19:17 2017 GMT
            Not After : Nov 30 04:19:18 2019 GMT
        Subject: CN=172.30.137.165
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:d9:94:79:45:02:ef:2e:9c:3c:7e:38:f4:18:06:
                    99:91:19:02:5e:7f:63:14:b0:c5:a3:78:ec:ac:bd:
                    17:5d:48:5e:95:f3:e5:bb:30:ed:ce:53:f6:df:4e:
                    a2:a0:ef:21:d3:1f:ee:c2:88:49:18:2d:d3:27:7f:
                    79:bb:e0:ae:dd:e7:31:d2:87:54:af:4a:2b:78:8e:
                    49:73:e8:99:77:0a:cd:48:30:0c:99:40:8f:e4:1c:
                    64:23:9b:97:55:d0:d1:f1:3c:e9:86:cf:5e:4d:ff:
                    a2:5e:f5:e5:02:6a:97:7f:40:9a:16:54:0c:25:34:
                    02:7d:19:14:7f:c5:22:26:78:79:6e:a9:e8:10:cf:
                    fa:ca:4c:c9:23:12:4c:ae:63:61:fd:9f:10:fa:0f:
                    6b:8d:de:58:fc:cc:29:40:94:92:c9:bc:f1:da:25:
                    ab:96:0e:42:1d:12:26:6a:84:9d:f5:95:1a:f9:e9:
                    f6:0a:9e:c1:df:6f:c0:20:0c:a8:85:e1:95:74:7b:
                    84:98:8f:c9:72:1d:f8:56:12:40:f9:fb:7a:9c:85:
                    5c:b2:e0:a7:db:8e:84:77:a1:88:95:da:b1:27:90:
                    21:fd:48:ea:a5:e5:00:28:b0:db:cb:1d:f7:ac:27:
                    82:cf:6b:21:db:a6:b2:43:6e:cb:11:61:87:2a:1e:
                    32:1d
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Alternative Name: 
                DNS:docker-registry-default.apps.s37.nekop.io, DNS:docker-registry.default.svc, DNS:docker-registry.default.svc.cluster.local, DNS:172.30.137.165, IP Address:172.30.137.165
    Signature Algorithm: sha256WithRSAEncryption
         6e:86:cc:92:73:5a:22:78:fc:83:a1:d7:06:f4:96:31:aa:cc:
         04:bb:9c:0d:fa:4b:fa:b3:7e:0c:7d:29:34:95:35:f3:f3:af:
         e7:84:86:14:e9:25:49:fa:54:5e:29:ad:5c:d3:36:e0:a1:38:
         7d:57:0d:53:24:6c:8e:ea:66:3a:81:9f:0a:90:f8:6a:e9:c9:
         9d:8d:68:2d:42:8e:41:fa:c8:da:06:1c:96:a1:69:ed:cf:4a:
         a0:12:b8:10:7c:e8:11:01:1f:70:e5:e6:6a:9a:9e:7e:46:5c:
         47:44:1e:96:70:9b:3d:6a:d2:77:fc:4f:9e:2a:e1:db:75:79:
         3c:86:09:58:53:df:f5:9d:28:68:5c:78:11:a4:45:b2:fc:b7:
         5b:09:bd:dd:32:94:c7:a3:65:ee:a2:50:c8:83:61:c4:a9:45:
         17:2f:28:d0:72:e7:16:28:6a:c4:0d:82:7a:93:01:08:06:ea:
         36:c5:ea:c3:36:fc:2d:ce:6c:f4:a4:90:c3:16:bf:ce:dc:c4:
         59:90:d2:91:fb:47:03:ab:25:e2:27:b3:61:06:a2:c4:0b:33:
         fa:16:8e:21:58:90:95:a5:a5:c3:e3:5f:a6:7d:6e:76:88:17:
         de:8d:a1:37:06:6b:22:77:f0:ea:60:80:ae:02:5b:f0:8a:06:
         31:94:ee:7a
-----BEGIN CERTIFICATE-----
MIIDiDCCAnCgAwIBAgIBBjANBgkqhkiG9w0BAQsFADAmMSQwIgYDVQQDDBtvcGVu
c2hpZnQtc2lnbmVyQDE1MTIwMTAzNzUwHhcNMTcxMTMwMDQxOTE3WhcNMTkxMTMw
MDQxOTE4WjAZMRcwFQYDVQQDEw4xNzIuMzAuMTM3LjE2NTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBANmUeUUC7y6cPH449BgGmZEZAl5/YxSwxaN47Ky9
F11IXpXz5bsw7c5T9t9OoqDvIdMf7sKISRgt0yd/ebvgrt3nMdKHVK9KK3iOSXPo
mXcKzUgwDJlAj+QcZCObl1XQ0fE86YbPXk3/ol715QJql39AmhZUDCU0An0ZFH/F
IiZ4eW6p6BDP+spMySMSTK5jYf2fEPoPa43eWPzMKUCUksm88dolq5YOQh0SJmqE
nfWVGvnp9gqewd9vwCAMqIXhlXR7hJiPyXId+FYSQPn7epyFXLLgp9uOhHehiJXa
sSeQIf1I6qXlACiw28sd96wngs9rIdumskNuyxFhhyoeMh0CAwEAAaOBzTCByjAO
BgNVHQ8BAf8EBAMCBaAwEwYDVR0lBAwwCgYIKwYBBQUHAwEwDAYDVR0TAQH/BAIw
ADCBlAYDVR0RBIGMMIGJgilkb2NrZXItcmVnaXN0cnktZGVmYXVsdC5hcHBzLnMz
Ny5uZWtvcC5pb4IbZG9ja2VyLXJlZ2lzdHJ5LmRlZmF1bHQuc3Zjgilkb2NrZXIt
cmVnaXN0cnkuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbIIOMTcyLjMwLjEzNy4x
NjWHBKweiaUwDQYJKoZIhvcNAQELBQADggEBAG6GzJJzWiJ4/IOh1wb0ljGqzAS7
nA36S/qzfgx9KTSVNfPzr+eEhhTpJUn6VF4prVzTNuChOH1XDVMkbI7qZjqBnwqQ
+GrpyZ2NaC1CjkH6yNoGHJahae3PSqASuBB86BEBH3Dl5mqann5GXEdEHpZwmz1q
0nf8T54q4dt1eTyGCVhT3/WdKGhceBGkRbL8t1sJvd0ylMejZe6iUMiDYcSpRRcv
KNBy5xYoasQNgnqTAQgG6jbF6sM2/C3ObPSkkMMWv87cxFmQ0pH7RwOrJeIns2EG
osQLM/oWjiFYkJWlpcPjX6Z9bnaIF96NoTcGayJ38OpggK4CW/CKBjGU7no=
-----END CERTIFICATE-----

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=openshift-signer@1512010375
        Validity
            Not Before: Nov 30 02:52:54 2017 GMT
            Not After : Nov 29 02:52:55 2022 GMT
        Subject: CN=openshift-signer@1512010375
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:d4:dc:77:69:ec:ae:5f:83:e1:52:8b:32:02:5f:
                    71:47:ee:2f:53:8e:73:4a:23:59:32:b8:b9:9d:c0:
                    f3:5b:f4:5e:30:f2:db:65:59:14:dc:3b:a5:2d:9b:
                    84:b9:24:6b:d0:7c:7f:c8:4b:4a:d4:bc:50:d2:e6:
                    f2:5e:1d:2a:b9:4a:29:76:63:d1:15:75:b5:ca:2a:
                    a5:9a:3d:f6:34:47:ac:81:39:c5:87:ca:03:58:9e:
                    f1:b3:94:11:b9:f2:e0:8b:3d:28:54:62:67:89:eb:
                    5a:7d:c6:d3:59:f1:61:58:6f:b8:11:22:dd:3f:cf:
                    a5:de:c0:44:20:86:93:b9:a5:c0:1e:79:3f:f4:bf:
                    4b:2c:fb:39:92:ec:eb:17:69:f0:8f:47:3a:96:a8:
                    c3:e6:4c:cc:57:c2:d1:a7:72:3b:b4:a0:dd:d0:23:
                    28:81:e3:e7:f0:23:ef:75:60:f0:71:19:20:07:1d:
                    28:dc:2f:ff:6a:8c:b6:e3:93:e1:6f:33:7f:3a:40:
                    6e:78:5b:11:d5:b8:9b:a4:ef:87:e1:e4:bf:d9:f8:
                    82:3d:7f:25:bf:9b:6d:b5:6e:34:20:6e:41:f3:a4:
                    1d:f2:89:79:98:ab:74:3a:26:05:a7:a0:6b:0b:43:
                    c5:e0:14:db:20:be:e1:06:4c:21:09:12:5b:69:e1:
                    04:d9
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment, Certificate Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
    Signature Algorithm: sha256WithRSAEncryption
         2a:d2:0e:6a:70:81:11:79:be:19:00:a4:db:5a:67:b5:67:df:
         50:62:b3:dd:c2:5d:7d:68:01:9f:39:cc:f1:d9:f7:9b:8d:a5:
         16:dd:7f:70:7b:c2:b0:cb:e0:4c:8e:20:4c:26:f7:8b:4d:5f:
         8d:51:fc:87:b4:a2:61:cf:91:17:69:6d:0c:f5:f4:35:a8:4f:
         91:14:06:1d:9e:7a:d2:e0:f9:8a:46:cf:01:54:19:25:b3:c8:
         9e:8d:c7:29:2b:fe:9d:72:82:9e:f5:f6:e4:e0:d7:c4:dd:2b:
         44:68:84:1c:4c:a7:91:b8:0c:7f:f6:c6:54:cb:98:be:30:56:
         8b:21:17:18:23:bc:7b:12:ca:7f:56:2a:9c:5c:01:e4:cc:6a:
         0b:a0:e6:09:e0:6d:9a:c2:30:1b:b4:23:a7:78:60:a9:bd:ef:
         3e:66:00:96:d1:c8:cc:25:a7:47:c1:48:e8:58:b1:04:e5:e8:
         ae:4c:61:05:67:bb:f3:15:3d:26:86:27:71:ef:e2:69:f4:58:
         8e:67:9e:a0:6f:84:44:03:3b:18:e5:68:0c:ee:0a:45:e5:c4:
         19:a6:cf:15:07:97:2a:09:64:e8:30:1f:46:cb:c8:af:5d:04:
         3f:c3:ee:1b:98:9a:b2:69:e4:19:de:bd:f5:56:99:08:51:97:
         d1:b4:33:8f
-----BEGIN CERTIFICATE-----
MIIC6jCCAdKgAwIBAgIBATANBgkqhkiG9w0BAQsFADAmMSQwIgYDVQQDDBtvcGVu
c2hpZnQtc2lnbmVyQDE1MTIwMTAzNzUwHhcNMTcxMTMwMDI1MjU0WhcNMjIxMTI5
MDI1MjU1WjAmMSQwIgYDVQQDDBtvcGVuc2hpZnQtc2lnbmVyQDE1MTIwMTAzNzUw
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDU3Hdp7K5fg+FSizICX3FH
7i9TjnNKI1kyuLmdwPNb9F4w8ttlWRTcO6Utm4S5JGvQfH/IS0rUvFDS5vJeHSq5
Sil2Y9EVdbXKKqWaPfY0R6yBOcWHygNYnvGzlBG58uCLPShUYmeJ61p9xtNZ8WFY
b7gRIt0/z6XewEQghpO5pcAeeT/0v0ss+zmS7OsXafCPRzqWqMPmTMxXwtGncju0
oN3QIyiB4+fwI+91YPBxGSAHHSjcL/9qjLbjk+FvM386QG54WxHVuJuk74fh5L/Z
+II9fyW/m221bjQgbkHzpB3yiXmYq3Q6JgWnoGsLQ8XgFNsgvuEGTCEJEltp4QTZ
AgMBAAGjIzAhMA4GA1UdDwEB/wQEAwICpDAPBgNVHRMBAf8EBTADAQH/MA0GCSqG
SIb3DQEBCwUAA4IBAQAq0g5qcIEReb4ZAKTbWme1Z99QYrPdwl19aAGfOczx2feb
jaUW3X9we8Kwy+BMjiBMJveLTV+NUfyHtKJhz5EXaW0M9fQ1qE+RFAYdnnrS4PmK
Rs8BVBkls8iejccpK/6dcoKe9fbk4NfE3StEaIQcTKeRuAx/9sZUy5i+MFaLIRcY
I7x7Esp/ViqcXAHkzGoLoOYJ4G2awjAbtCOneGCpve8+ZgCW0cjMJadHwUjoWLEE
5eiuTGEFZ7vzFT0mhidx7+Jp9FiOZ56gb4REAzsY5WgM7gpF5cQZps8VB5cqCWTo
MB9Gy8ivXQQ/w+4bmJqyaeQZ3r31VpkIUZfRtDOP
-----END CERTIFICATE-----

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=openshift-signer@1512010375
        Validity
            Not Before: Nov 30 02:52:54 2017 GMT
            Not After : Nov 29 02:52:55 2022 GMT
        Subject: CN=openshift-signer@1512010375
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:d4:dc:77:69:ec:ae:5f:83:e1:52:8b:32:02:5f:
                    71:47:ee:2f:53:8e:73:4a:23:59:32:b8:b9:9d:c0:
                    f3:5b:f4:5e:30:f2:db:65:59:14:dc:3b:a5:2d:9b:
                    84:b9:24:6b:d0:7c:7f:c8:4b:4a:d4:bc:50:d2:e6:
                    f2:5e:1d:2a:b9:4a:29:76:63:d1:15:75:b5:ca:2a:
                    a5:9a:3d:f6:34:47:ac:81:39:c5:87:ca:03:58:9e:
                    f1:b3:94:11:b9:f2:e0:8b:3d:28:54:62:67:89:eb:
                    5a:7d:c6:d3:59:f1:61:58:6f:b8:11:22:dd:3f:cf:
                    a5:de:c0:44:20:86:93:b9:a5:c0:1e:79:3f:f4:bf:
                    4b:2c:fb:39:92:ec:eb:17:69:f0:8f:47:3a:96:a8:
                    c3:e6:4c:cc:57:c2:d1:a7:72:3b:b4:a0:dd:d0:23:
                    28:81:e3:e7:f0:23:ef:75:60:f0:71:19:20:07:1d:
                    28:dc:2f:ff:6a:8c:b6:e3:93:e1:6f:33:7f:3a:40:
                    6e:78:5b:11:d5:b8:9b:a4:ef:87:e1:e4:bf:d9:f8:
                    82:3d:7f:25:bf:9b:6d:b5:6e:34:20:6e:41:f3:a4:
                    1d:f2:89:79:98:ab:74:3a:26:05:a7:a0:6b:0b:43:
                    c5:e0:14:db:20:be:e1:06:4c:21:09:12:5b:69:e1:
                    04:d9
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment, Certificate Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
    Signature Algorithm: sha256WithRSAEncryption
         2a:d2:0e:6a:70:81:11:79:be:19:00:a4:db:5a:67:b5:67:df:
         50:62:b3:dd:c2:5d:7d:68:01:9f:39:cc:f1:d9:f7:9b:8d:a5:
         16:dd:7f:70:7b:c2:b0:cb:e0:4c:8e:20:4c:26:f7:8b:4d:5f:
         8d:51:fc:87:b4:a2:61:cf:91:17:69:6d:0c:f5:f4:35:a8:4f:
         91:14:06:1d:9e:7a:d2:e0:f9:8a:46:cf:01:54:19:25:b3:c8:
         9e:8d:c7:29:2b:fe:9d:72:82:9e:f5:f6:e4:e0:d7:c4:dd:2b:
         44:68:84:1c:4c:a7:91:b8:0c:7f:f6:c6:54:cb:98:be:30:56:
         8b:21:17:18:23:bc:7b:12:ca:7f:56:2a:9c:5c:01:e4:cc:6a:
         0b:a0:e6:09:e0:6d:9a:c2:30:1b:b4:23:a7:78:60:a9:bd:ef:
         3e:66:00:96:d1:c8:cc:25:a7:47:c1:48:e8:58:b1:04:e5:e8:
         ae:4c:61:05:67:bb:f3:15:3d:26:86:27:71:ef:e2:69:f4:58:
         8e:67:9e:a0:6f:84:44:03:3b:18:e5:68:0c:ee:0a:45:e5:c4:
         19:a6:cf:15:07:97:2a:09:64:e8:30:1f:46:cb:c8:af:5d:04:
         3f:c3:ee:1b:98:9a:b2:69:e4:19:de:bd:f5:56:99:08:51:97:
         d1:b4:33:8f
-----BEGIN CERTIFICATE-----
MIIC6jCCAdKgAwIBAgIBATANBgkqhkiG9w0BAQsFADAmMSQwIgYDVQQDDBtvcGVu
c2hpZnQtc2lnbmVyQDE1MTIwMTAzNzUwHhcNMTcxMTMwMDI1MjU0WhcNMjIxMTI5
MDI1MjU1WjAmMSQwIgYDVQQDDBtvcGVuc2hpZnQtc2lnbmVyQDE1MTIwMTAzNzUw
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDU3Hdp7K5fg+FSizICX3FH
7i9TjnNKI1kyuLmdwPNb9F4w8ttlWRTcO6Utm4S5JGvQfH/IS0rUvFDS5vJeHSq5
Sil2Y9EVdbXKKqWaPfY0R6yBOcWHygNYnvGzlBG58uCLPShUYmeJ61p9xtNZ8WFY
b7gRIt0/z6XewEQghpO5pcAeeT/0v0ss+zmS7OsXafCPRzqWqMPmTMxXwtGncju0
oN3QIyiB4+fwI+91YPBxGSAHHSjcL/9qjLbjk+FvM386QG54WxHVuJuk74fh5L/Z
+II9fyW/m221bjQgbkHzpB3yiXmYq3Q6JgWnoGsLQ8XgFNsgvuEGTCEJEltp4QTZ
AgMBAAGjIzAhMA4GA1UdDwEB/wQEAwICpDAPBgNVHRMBAf8EBTADAQH/MA0GCSqG
SIb3DQEBCwUAA4IBAQAq0g5qcIEReb4ZAKTbWme1Z99QYrPdwl19aAGfOczx2feb
jaUW3X9we8Kwy+BMjiBMJveLTV+NUfyHtKJhz5EXaW0M9fQ1qE+RFAYdnnrS4PmK
Rs8BVBkls8iejccpK/6dcoKe9fbk4NfE3StEaIQcTKeRuAx/9sZUy5i+MFaLIRcY
I7x7Esp/ViqcXAHkzGoLoOYJ4G2awjAbtCOneGCpve8+ZgCW0cjMJadHwUjoWLEE
5eiuTGEFZ7vzFT0mhidx7+Jp9FiOZ56gb4REAzsY5WgM7gpF5cQZps8VB5cqCWTo
MB9Gy8ivXQQ/w+4bmJqyaeQZ3r31VpkIUZfRtDOP
-----END CERTIFICATE-----

でもここまでワンライナーでやるのはちょっとやりすぎなので、良い子は適度に分けましょう。

$ oc get secret registry-certificates --template='{{index .data "registry.crt"}}' | base64 -d > chained-server.crt
$ openssl crl2pkcs7 -nocrl -certfile chained-server.crt | openssl pkcs7 -print_certs -text

ちなみに証明書情報の表示は一般的にopenssl x509コマンドを利用しますが、openssl x509は先頭の証明書の情報しか表示しないので、Webサーバに設定するようなchained形式の複数の証明書の情報表示は上のopenssl pkcs7コマンドを利用します。

OpenShiftのImageStream

OpenShift 全部俺 Advent Calendar 2017

OpenShiftにはKubernetesに無いImageStreamというオブジェクトがあります。ImageStreamは内部的にタグに対応するDockerレジストリを管理し、それに追加で機能を提供します。ImageStreamは大きく以下の三つの機能を提供しています。

  • Dockerレジストリのタグにpushされたイメージのバージョン履歴(Stream)を保持する機能
    • 実際にはImageStreamのタグは「Dockerレジストリのタグ」だけではなく任意のコンテナイメージ履歴をトラックできる、後述のイメージプロモーションなど
  • Dockerレジストリにpushなど、ImageStreamのタグが更新されたら自動的にアクションを起動できるImageChange更新トリガーの提供
  • OpenShift内部レジストリとの連携、イメージキャッシュ

ImageStreamは内部で管理されるDockerレジストリのイメージのメタデータを参照しています。イメージのレイヤーデータは保持していません。oc explain isのdescriptionは以下のようになっています。

ImageStream stores a mapping of tags to images, metadata overrides that are applied when images are tagged in a stream, and an optional reference to a Docker image repository on a registry.

OpenShiftのBuildConfig、DeploymentConfigはこのImageStreamの機能を利用することにより、たとえばベースイメージのセキュリティ脆弱性の修正を更新をトリガーに、それに依存しているコンテナを全て再ビルド再デプロイしてセキュリティ修正を反映させる、というようなユースケースが実現できます。ImageStreamはこのようなコンテナイメージの管理の効率化、自動化を行う上で必要となる機能を提供しています。

たとえばdev, test, stage, prodというようなタグを定義しておき、devはDockerレジストリapp:latestに対応していて開発者によりpushされ継続的に更新されている、それをテスト環境へリリースするにはoc tag app:dev app:testを実行するとその時点でのapp:devが指しているイメージがapp:testタグに追加され、ImageChangeトリガーによってテスト環境へリリースされる、というようなイメージプロモーションによる迅速なリリースを実現することができます。

https://docs.openshift.org/3.11/dev_guide/application_lifecycle/promoting_applications.html

KubernetesにはOpenShiftのDeploymentConfig由来のDeploymentsというオブジェクトがありますが、KubernetesにはImageStreamがないので、その関連機能ももちろんスコープ外となっており、OpenShiftのDeploymentConfigの方が基本的には高機能なものとなっています。

Resources