title: 【從題目中學習k8s】-【Day7】K8s中的TLS
description: 以無比的恆毅力堅持30天鍊成鐵人--連續30天，一天發表一篇IT技術文章

【從題目中學習k8s】-【Day7】K8s中的TLS

tags: DevOps CICD K8s Docker

前言

今天筆者想介紹K8s中的TLS，也就是Transport Layer Security。K8s中的TLS說實在滿複雜的，所以筆者想先從基礎的TLS開始講起，先有個概念後會比較好延伸。如果你已經了解TLS了，那麼就直接跳過前面的介紹吧!那我們開始囉~

TLS簡介

TLS存在的目的只有一個，那就是"確保Client和Server的訊息傳輸是安全的"。這句話看起來像廢話 (事實上就是)，但要達到這個目的其實要確實做到兩件事:

1. 確保傳輸的資料是加密且無法被破解的
2. 確保Server是非偽造的

對稱式加密

舉個例子，當有個User要存取某個Web Application，需要輸入帳號密碼等使用者資訊，這些資訊會以明文(plain text)的方式在網路中傳輸，因此Hacker很容易可以取得這些資料。為了預防這個情況發生，我們會將資料加密，例如random產生一個key然後以XOR等方式加密資料後傳輸，如此即使Hacker真的取得傳輸資料，他取得的也是加密後的資料，無法做任何事。但是Web Server收到的資料同時也是加密後的資料，它一樣無法解讀，因此User必須將key也傳給Web Server，Web Server收到加密資料及key後再進行解密。

這種傳送加密資料，並以相同的key進行加密及解密的方法，就是經典的"對稱式加密(Symmetric Encryption)"

但是問題來了，Hacker既然可以取得加密資料，當然也有辦法取得你的key阿，畢竟是在同一個網路上做傳輸的，沒道理他取不到吧。因此，對稱式加密顯而易見的缺點就是，要是這把鑰匙被中間人竊聽到了，那之後所有攔截到的加密訊息，都能被輕易破解，因為它加解密的方法都是同一把key。為了解決這個問題，就有了所謂 "非對稱式加密(Asymmetric Encryption)"。

非對稱式加密

"非對稱式加密(Asymmetric Encryption)" 就是每個使用者都擁有"一對金鑰"，一把Public Key，一把Private Key。

你可以把Public Key想像成是一個鎖(lock)，而Private Key是用來解這把鎖的鑰匙(key)。鎖是大家都可以來解的，所以它是public，而鑰匙卻只有我有，所以是private的。

(這種說法不是很嚴謹，因為事實上兩把都是key，並沒有一定是誰解誰，這樣舉例只是方便大家理解~)

我們以SSH當作例子，當Client想要access目標Server時，Client會產生一對金鑰。輸入ssh-keygen會產生兩個檔案: id_rsa和id_rsa.pub，分別是Private Key 和 Public Key(lock)。
接著將目標Server以Public Key lock住，確保它是安全的。作法通常是在Server的~/.ssh/authorized_keys中用Public Key 加入一個entry。

$ vim ~/.ssh/authorized_keys

ssh-rsa <public key> <user-name>

這時Client即可透過Private Key存取Server

$ ssh -i id_rsa <user-name>@<server-name>
Successfully Logged In!

確保傳輸的資料是加密且無法被破解的

剛剛我們提到TLS的安全需要確保傳輸的資料是加密且無法被破解的，那麼要如何辦到呢?我們以剛剛的Web Applcation 當作例子，有Client和目標Server，Client產生一把Symmetric Key(以下簡稱CK)，Server則產生一對金鑰，即一個Private Key(以下簡稱SK) 和一個 Public Key(以下簡稱PK)。

要注意，Public Key是公開在網路上的，理論上所有人都知道，而Private Key只有擁有者知道

當Client以https存取網站時，即得到Web Server公開的PK

1. Client將CK以PK加密，並將加密後的CK傳送至Server
   
2. Server將加密的CK以SK解密，得到原先的CK
   
3. Client將要傳送的機密資料以CK加密後傳送到Server
   
4. Server將資料以CK解密後，即可得到原始資料
   

這樣的作法就可以保證Hacker無法破解資料，為啥呢?
因為在整個資料傳輸及金鑰交換的過程中，Hacker只能取得以下東西

1. Server的PK
2. 以PK加密後的CK
3. 以CK加密後的資料

如此一來，Hacker無法得到CK(Hacker雖然得到加密後的CK，但是沒有SK就無法破解)，當然也無法破解原始資料拉~

確保此Server是真的

但是Hacker也不是省油的燈呀，它可能會產生類似的一組SK跟PK，然後將你的目的地位址導到Hacker的Fake Server，然後用一樣的流程得到你的資料。那要怎麼防止這個情況發生呢? 其實就是一開始獲得PK的方式啦，只要我們確認這個PK是來自真實Server而非Fake Server，那就可以確保傳輸的安全性。至於要如何確認，就是讓Server在給Client 這個PK時，不要直接給PK，而是透過Certificate的方式，而PK則放在其中。這個Certificate會包含一些資訊，像是Server的PK、Server的位址等。

但是你可能會想，Hacker也可能會偽造Certificate阿，那不就沒用了?沒錯，所以Certificate的"簽章(signature)"就變得非常重要。誰創建這個Certificate，誰就必須在上面簽章。所以假的Certificate上面就是Hacker的數位簽章喔~
大部分的Web Browser都有 Certificate Validation Mechanism，所以當你在瀏覽https網站時，常常在URL前會有個"Not secure"的提醒，就是因為Browser認為這個Certificate可能是假的，在警告你喔~
那麼，要如何得知那些Certificate是合法的，哪些是不合法的呢?這就是CA(Certificate Authority)的工作啦~

CA

CA通常是世界上知名的組織，他們可以為你的Certificate簽章和認證，藉此保證你Certificate的合法性。著名的CA像是:

• Symantec
• DigiCert
• Comodo
• GlobalSign

Server會先產生CSR(Certificate Singing Request)到CA請求簽章，CA會檢查CSR中的資訊，若認定Server為合法則會為其簽章，並送回Certificate至Server。至此，Server即擁有Browser認定合法的Certificate了。

若Hacker想產生一組相同的合法Certificate，到CA這關就會卡關啦~
至於CA是如何判定你是不是合法用戶，這就是它們自己的方法了，筆者也不是很清楚，有興趣的朋友再自己研究囉!

可是還有個問題，Browser要怎麼認定這個Certificate是經由合法CA簽章的，而不是Fake CA呢? 答案是CA自己也會有一組金鑰啦~所有合法CA的Public Key會內嵌在Browser中，而Private Key則由CA自己保存。這樣一來Brower就可以透過這一組金鑰來驗證Certificate是不是由真實CA簽章的囉~

綜合以上這些流程，包含CA、Server、Client、Certificate等等的，就是所謂的
PKI(Public Key Infrastructure)。

總結一下上述的流程，我們一共會有三組金鑰:

1. Server Certificates : 確保傳輸資料安全
2. Root Certificates : 為Server Certificates簽章
3. Server Certificates : Client的認證
   

Public Key的檔名通常是*.crt, *.pem，例如:

• server.crt
• server.pem
• client.crt
• client.pem

Private Key的檔名通常是*.key, *-key.pem，例如:

• server.key
• server-key.pem
• client.key
• client-key.pem

K8s中的TLS

在K8s集群中，Control Plane和Node間、Node和Node間及Administrator和Control Plane之間的連線傳輸都必須確保是安全的，因此他們之間都必須建立TLS連線。K8s中會用到的Certificates有 Client Certificates及 Server Certificates。我們分別列出此兩種Certificates會用到的key及crt，以及他們分別屬於那些元件。要記住，一個元件不一定只有Server或Client的身分，它也可能同時兼具。例如apiserver，它既是admin、kube-scheduler、controller-manager及kube-proxy下達指令的對象(作為Server)，亦是向etcd發出request的Client。K8s中的Certificates和key一共有下列這些：

觀察kube-apiserver的設定檔可以發現K8s認證所需的key和csr會放在/etc/kubernetes/pki目錄下

結論

今天算是比較general的介紹一下TLS的流程以及K8s中TLS的元件有哪些，筆者覺得有個概念即可，有機會後面做題目時再講的細一點。好啦，今天就到這裡啦~ 謝謝大家~

參考資料

簡介 SSL、TLS 協定
基礎密碼學(對稱式與非對稱式加密技術)
Manage TLS Certificates in a Cluster
PKI Bootcamp - What is a PKI?
PKI certificates and requirements

Thank you!

You can find me on

• george4908090@gmail.com