kubestronautへの道 ~CKS編 その7 killer coda「CertificateSigningRequests sign manually」~

tech article
2024.07.31

今日覚えて帰ること

CSRってなに？

  • 認証局（CA）に証明書を作ってもらうためのファイル
  • 「公開鍵」「識別情報」「署名」で構成される
  • 署名部分を除いたCSRの内容をハッシュ化し、それを秘密鍵で暗号化したものが「署名」

CertificateSigningRequests sign manually

In the first step we’ll create a CSR and in the second step we’ll manually sign the CSR with the K8s CA file.

The idea here is to create a new “user” that can communicate with K8s.

For this now:

  1. Create a new KEY at /root/60099.key for user named 60099@internal.users
  2. Create a CSR at /root/60099.csr for the KEY

手動で証明書を作成する問題です。

Create KEY and CSR

まずは秘密鍵とCSR(CertificateSigningRequests/証明書署名要求)を作成します。

CSRはKubernetesにおけるリソースの一種です。
CSRを使って、クライアント（Kubetctlを利用するユーザーやServiceAccountなど）用の署名つき証明書をCAに要求します。

それとは別に、一般的に電子署名を行う際にもCSRファイルを使用します。
今回は後者のCSRについて勉強していきます。

CSRは「公開鍵」「識別情報」「署名」で構成されます。
「署名」がちょっとわかりづらいですが、「署名部分を除いたCSRの内容をハッシュ化し、それを秘密鍵で暗号化したもの」と思っておけばいいみたいです。

以下の記事がとても参考になりました。

Open-SSLで作ったCSRファイルの電子署名を解析してみた - Qiita
はじめにある日偉い人から「Open-SSLで作った証明書署名要求(CSR)の中にある電子署名の仕組みを説明してね」と言われたため色んなサイトを巡って電子署名の勉強をしました。折角学んだ事なのでこ…
qiita.com

それではCSRを作成していきましょう。
以下のページの手順が参考になります。（しかし結構手順は違います。）

証明書を手動で生成する
クライアント証明書認証を使用する場合、easyrsa、opensslまたはcfsslを使って手動で証明書を生成することができます。 easyrsa easyrsaはクラスターの証明書を手動で生成することができます。 パッチが適用されたバージョンのeasyrsa3をダウンロードして解凍し、初期化します。 curl -LO...
kubernetes.io

2048bitの秘密鍵を生成します

controlplane $ openssl genrsa -out /root/60099.key  2048
Generating RSA private key, 2048 bit long modulus (2 primes)
........................................................................................................+++++
...........+++++
e is 65537 (0x010001)
controlplane $

秘密鍵を用いてCSRを生成します。
ここでのCSRはKubernetsリソースではなく、一般的なCSRです。
CN(Common Name)を指定しろという条件があったのでこのフィールドのみ指定します。
オプションで設定ファイルを指定していれば対話的にフィールドを入力しなくて済みます。

controlplane $ openssl req -new -key /root/60099.key -out /root/60099.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:60099@internal.users
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
controlplane $

Manual signing

Manually sign the CSR with the K8s CA file to generate the CRT at /root/60099.crt .

Create a new context for kubectl named 60099@internal.users which uses this CRT to connect to K8s.

CAファイルを使ってCSRに署名し、証明書を生成します。
CAファイルが認証局的な働きをしてるって感じなんですかね？

controlplane $ openssl x509 -req -in /root/60099.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out /root/60099.crt -days 500

Signature ok
subject=C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN = 60099@internal.users
Getting CA Private Key
controlplane $

openssl x509

x509証明書を作成する、と言っています。

-req -in /root/60099.csr

CSRを使用し、そのCSRは/root/60099.csrである、と言っています。

-CA /etc/kubernetes/pki/ca.crt

CAの公開証明書（≒公開鍵）を指定しています。
今から作る証明書（クライアント証明書）の検証はこれを使ってね、と言っています。

-CAkey /etc/kubernetes/pki/ca.key

CAの秘密鍵を指定しています。
今から作る証明書（クライアント証明書）にはこの秘密鍵を使って署名する、と言っています。

-CAcreateserial

シリアル番号を管理するためのファイルを自動的に作成する、と言っています。
さしあたって理解しなくてよさそうです。

-out /root/60099.crt -days 500

/root/60099.crtに証明書を出力し、有効期限は500日だ、と言っています。

ハチャメチャに難しいです。
CKSで出題されないことを祈ります。
手順自体は公式ページに載ってるんですけどね。

ちなみに、証明書の構成要素は以下のような形らしいです（GPT調べ）

  • バージョン（Version）
  • シリアル番号（Serial Number）
  • 署名アルゴリズム（Signature Algorithm）
  • 発行者（Issuer）
  • 有効期間（Validity）
  • サブジェクト（Subject）
  • サブジェクトの公開鍵情報（Subject Public Key Info）
  • 拡張フィールド（Extensions）（バージョン3の証明書のみ）
  • 署名（Signature）
  • フィンガープリント（Fingerprint）

次に 60099@internal.users が kubectlを使えるように context を設定していきます

Certificates and Certificate Signing Requests
Kubernetes certificate and trust bundle APIs enable automation of X.509 credential provisioning by providing a programmatic interface for clients of the Kuberne...
kubernetes.io

まず、新しい資格情報を追加します。

controlplane $ k config set-credentials 60099@internal.users --client-key=/root/60099.key --client-certificate=/root/60099.crt
User "60099@internal.users" set.

次に、コンテキストを追加します。

controlplane $ k config set-context 60099@internal.users --cluster=kubernetes --user=60099@internal.users
Context "60099@internal.users" created.

確認します。

controlplane $ k config get-contexts
CURRENT   NAME                          CLUSTER      AUTHINFO               NAMESPACE
          60099@internal.users          kubernetes   60099@internal.users   
*         kubernetes-admin@kubernetes   kubernetes   kubernetes-admin

設定したコンテキストを使います。

controlplane $ k config use-context 60099@internal.users
Switched to context "60099@internal.users".

確認します。
認可はされませんが、認証されていることがわかります。

controlplane $ k get ns
Error from server (Forbidden): namespaces is forbidden: User "60099@internal.users" cannot list resource "namespaces" in API group "" at the cluster scope
タイトルとURLをコピーしました