對稱式加密(Symmetric Encryption):
為了解決上述請求在網路傳遞過程中因為是明碼,會有被駭客截獲的問題
所以發展出來的方式就是Client端加密與Server端解密
要完成這兩端的加解密則需要共同擁有同一把鑰匙(String key)
這種共用相同鑰匙的機制就是對稱式加密(Symmetric Encryption)
其鑰匙也被稱為對稱式鑰匙(Symmetric key)
過程傳遞在Internet的加密內容就算被駭客截獲,駭客沒有鑰匙也沒辦法解讀
但是這邊就有一個問題,我們總不可能都跟全部的Server都共用鑰匙
所以一個方式就是把鑰匙也從Client遞送過去到Server端
但是就又延伸駭客也能截獲鑰匙的問題!
所以又延伸以下解決方案
非同步加密(Asymmetric Encryption):
首先除了上述的加解密鑰匙保留外,在建立另一組加密與解密鑰匙:
- 加密鑰匙
- 解密鑰匙
或稱為key-pair
首先Server端建立出加密鑰匙與解密鑰匙對(簡單圖示):
並將其中一把key交給Client(同時可以預想到駭客也能截獲這個key):
接著Client端拿著Server提供的key將前面提到的對稱式鑰匙加密
得到
接著將加密後的對稱式鑰匙交給Server(同理駭客也能拿到):
但是最後能解開的只有Server持有的另一把key-pair鑰匙能解開
但是駭客沒有那個紅色的key-pair,所以解不開
其中Server提供給Client的key又稱作public key
而Server本身持有的另一把(紅色的)key-pair又稱為private key
所以整個鑰匙對又稱為:public private key pair
憑證機構(Certificate Authority):
經過上述機制,駭客已經無法從Client請求中截獲任何有用資訊
演變後駭客反而會去偽裝成假的Server端(網站)等等
並且駭客的網站也會有key-pair讓client端傳遞加密後的對稱式鑰匙
而為了避免這一類問題,憑證(Certificate)就進來了
真正的公司網站會將公鑰(public key)拿去給CA(Certificate Authority)
讓CA將公鑰做簽署(signed)並取得CA發佈的憑證(Certificates)
用上述電子憑證以認證公司網站的真實性,證明其公鑰是真的網站發出的
其中這個CA發佈給公司的電子憑證包含以下幾個東西:
- 嵌入的公鑰(public key)
- 網站名稱(name of website)與subdomains
- CA的簽署(Signature)
所以當Client透過瀏覽器瀏覽公司網站
瀏覽器會去檢視該網站的憑證是否合法,並且有無過期
客戶端憑證(Client Certificates):
而反過來公司網站也要避免駭客假裝一般Client發動請求
所以Client也要有憑證(Certificates)
但是一般Client不用主動做這件事,不然瀏覽網站就變得很麻煩
之後我們會產出一個client端憑證來連線到K8s API Server
信任與非信任CA(Certificate Authorities):
同前面所述,正當公司網站取得正當的CA憑證
但是一般的Client端如何辨別該網站的憑證是有效的?
並且如果有駭客也有做憑證放在網站上(可能不是CA簽發的)
Client端(又或說瀏覽器)要如何辨識?
答案是有一份授權認證的CA憑證清單
多數現代運行系統已將此清單打包其中
所以我們的瀏覽器就包含了這一份清單
所以針對駭客自行簽發的CA憑證,瀏覽器就會提示不認得其憑證
這類自行簽發的CA憑證又稱為自簽憑證(Self-Signed Certificate)
(通常公司內部也會用)
建立Key-pair與憑證請求(Request Certificate):
例如透過openssl工具產生key-pair:
openssl req -new -key great-bank.key -out great-bank.csr -subj "/C=US/ST=NY/O=GreatBankOrg,Inc./CN=great-bank.com
透過上述工具指令可以取得一把私鑰
並且透過該私鑰產生出Certificate Siging Request(CSR)檔
(CSR其中含有public key在裡面)
將上述CSR交給CA單位
CA單位確認內容後就做簽署(通常駭客在這一步申請就會失敗)
最後將簽署後的檔案返還給公司單位使用
而在K8s中針對憑證的發佈,認證,維護,Server key等等有一個統一介面管理:
Public Key Infrastructure(PKI)
