Cncf k8s Ingress Example-03
•
1 gefällt mir•767 views
Ingress & Ingress Controller範例(Part3) 目的 在一般企業環境內, 在注重網路安全的年代裡, 通常都會要求Web應用程式必須使用Https(443)的協議來確保Web client對Web server之間的網路封包不會因為沒有加密而外洩了重要的資訊。 然而現實的環境裡, 仍然有很多legacy的Web應用程式不容易(或不想)再修改來引人SSL的機制。這個時候, 最簡易的方法就是通過反向代理的伺服器在前端Web應用程式來進行SSL的握手協議, 然後再使用Http(80)的明文協議轉拋呼叫給後面Web應用程式。 雖然並不鼓勵這樣的做法, 但卻也是用最少的代價來啟動Https(443)的過渡方針。 範例 範例(3):是對反向代理SSL通信模型的”復現“，即client與ingress controller(nginx)間採用https加密通信，但ingress controller(nginx)與app3間則是明文的http通信。 為了讓ingress controller能夠進行SSL的通信握手, 必須要把SSL憑證上傳進Kubernetes裡, 然後設定Ingress來使用。 Youtube: https://youtu.be/gHNqwI378Hk Github: https://github.com/erhwenkuo/cncf-k8s
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Cncf k8s Ingress Example-03
Ähnlich wie Cncf k8s Ingress Example-03 (20)
Mehr von Erhwen Kuo
Mehr von Erhwen Kuo (19)
Cncf k8s Ingress Example-03
- 1. Cloud Native: Kubernetes Network Ingress & Ingress Controller 範例 Part#3 1
- 2. About Me • 5年的⽣產管理/物料管理 • 3年的MES/SFC系統開發運維 • 3年的ERP (SAP-MM模組)/EAI 的導入開發Leader • 2年的End-To-End Business Integration Analyst • 1年的OEM Sales Team Leader • 4年的企業營運分析/集團合併財報系統 • 6年的⼤數據新技術研究/推廣 • 緯創IT先進技術實驗室 – 主持⼈ • 緯創⼯業4.0 / 數位轉型 - 架構師 erhwenkuo@gmail.com 2 （⼆哥）
- 3. 3 Credit 本篇文章主要從”Tony Bai”個⼈部落格裡的2篇文章摘錄編 修⽽成 • 实践kubernetes ingress controller的四个例⼦ • https://tonybai.com/2018/06/21/kubernetes-ingress- controller-practice-using-four-examples/ • HTTPS服务的Kubernetes ingress配置实践 • https://tonybai.com/2018/06/25/the-kubernetes-ingress- practice-for-https-service/
- 4. 4 Credit 本篇文章有關SSL憑證的相關資訊, 主要從Carl在Medium裡”那些關於 SSL/TLS的⼆三事”的系列文章中擷取摘要 • 那些關於SSL/TLS的⼆三事(⼀) — Why SSL/TLS? • 那些關於SSL/TLS的⼆三事(⼆) — How SSL works? • 那些關於SSL/TLS的⼆三事(三) —給誰簽? • 那些關於SSL/TLS的⼆三事(⼗⼆) — Chain of Trust
- 5. 5 The Design Of Kubernetes • 接⼝層：kubectl 命令⾏⼯具、客⼾端 SDK 以 及集群聯邦 • 管理層：系統度量（如基礎設施、容器和網 絡的度量），⾃動化（如⾃動擴展、動態 Provision 等）以及策略管理（RBAC、Quota、 PSP、NetworkPolicy 等） • 應⽤層：部署（無狀態應⽤、有狀態應⽤、 批處理任務、集群應⽤等）和路由（服務發現、 DNS 解析等） • 核⼼層：Kubernetes 最核⼼的功能，對外提供 API 構建⾼層的應⽤，對內提供插件式應⽤執 ⾏環境 • ⽣態系統：在接⼝層之上的龐⼤ 容器集群管理調度的⽣態系統 • Kubernetes 外部：⽇誌、監控、 配置管理、CI、CD、Workflow、 FaaS、OTS 應⽤、ChatOps 等 • Kubernetes 內部：CRI、CNI、 CVI、鏡像倉庫、Cloud Provider、 集群⾃⾝的配置和管理等
- 6. 6 前⾔ • 這篇文章是ingress-nginx controller的範例系列 • 我們將通過五個範例來說明ingress-nginx在不同服務場景下的使⽤ 和配置⽅法 • 本文是範例#3
- 7. 7 前置準備 • 在進⾏範例之前, 請確定以下的條件: • Kubernetes集群正確運⾏ • ingress-nginx正確安裝與運⾏ • 詳細說明⾒: https://www.slideshare.net/erhwenkuo/cncf- k8snetwork03-ingress-introduction • Golang開發環境安裝(Optional) • 要編譯範例Golang的程式 • Openssl模組安裝 • 要產⽣⾃簽的SSL憑證
- 10. 10 關於SSL/TLS的⼆三事 Why SSL/TLS? • 由於之後的範例都會跟SSL/TLS的概念有關, 因此在練習範例之 前, 我們來補充⼀些跟SSL/TLS的基本知識: • 當使⽤者登入到網站時, 如銀⾏的網⾴, 使⽤者會需要確認所到達的 ⾴⾯確實是這個銀⾏的網⾴ • 使⽤者會想要避免任何在相同的domain name下看到相似的網站之可 能性 • SSL可以協助我們驗證正在存取的網站到底是正牌的還是假冒的。這 背後的機制是在瀏覽器上透過⼀些密碼學機制來達成的 • 瀏覽器會通過驗證SSL憑證裡的簽章來確認其真實性
- 11. 11 關於SSL/TLS的⼆三事 Why SSL/TLS? Security against Man-in-the-middle (MITM) attacks : 範例#3,#4 (會不會有⼈看到我在網站上輸入的信⽤卡卡號呢?) • SSL通訊可以確保透過其傳輸的資料都是由某個secret key加密過的, 且此 secret key只有client與server才知道, 並且對於每個唯⼀的session, 其secret key都是不同的。 Client/Server authentication: 範例#5 (瀏覽器會識別與認證server的真實性, 那server也可以識別client嗎?) • SSL允許雙向的認證. 瀏覽器可以驗證其正在存取的網站的⾝份, 網站也可以 透過client憑證來驗證client的真實性。在SSL通訊中, client憑證是⼀個選擇性 的步驟, 其並不是那麼的常⾒。
- 13. 13 關於SSL/TLS的⼆三事 Who signed the certificate? 這邊要來看⼀下兩種不同的憑證簽署⽅式: 誰來簽? ⼀般來說, ⼤概只分成CA簽或 是⾃⼰簽: • CA簽 • domain/website的管理者會對中意的CA送出⼀個憑證簽署請求, 要求該 CA使⽤其⾃⾝的私鑰對憑證進⾏簽章的動作。通常這種憑證的可信度 是比較⾼的, 畢竟要能取得CA的⾝份其實都暗⽰了其公鑰應該都是被⼤ 部分的瀏覽器所擁有的。對於公開網站來說, CA簽是比較理想的選擇。 • ⾃簽 • 通常是在組織內部網站使⽤。在這種情境下, 通常都會知道有哪些host 會想要存取網站, ⽽管理員也應該在憑證更新或是更換的時候更新所有 的host。這邊要注意的是, 所有的根憑證(root certificate)都是⾃簽的, 這 也是為什麼根憑證必須跟瀏覽器綁(bundled)在⼀起的原因。
- 14. 14 關於SSL/TLS的⼆三事 Who signed the certificate? 再來可以看⼀下這張比較表:
- 15. 15 關於SSL/TLS的⼆三事 Who signed the certificate? 建立⾃⼰的私⼈CA⽤以簽署⾃⼰的憑證: • 就如同⼤多數的CA發⾏⾃⼰的根憑證給瀏覽器廠商⼀樣, 你也可以有⾃⼰的 私⼈CA⽤來簽⾃⼰的憑證。 • 很多組織會採取此⽅式以便管理憑證(為了其組織內部使⽤) 。在這種情境下, 這些組織建立私有CA然後把這個私有CA的公鑰加入到所有該組織所屬的機器 中的瀏覽器上, 這部分可能會透過⼀些協作系統(orchestration system)如 Chef/puppet來完成。 • 如此⼀來, 就可以讓所有的SSL憑證都給這個私有CA簽署了。對於這種⽅式還 有⼀種可能的好處: 由於CA的PK都不會改變(如果這個組織從頭到尾都只⽤⼀ 開始⽣出來的那個公鑰的話), 所以也不需要去加入新的憑證到組織內的瀏覽 器上(對內部使⽤的情境⽽⾔) 。
- 16. 16 關於SSL/TLS的⼆三事 Chain of Trust 所謂的信任鍊: • 在實務上, SSL 憑證通常不是直接由 Root CA 進⾏簽核的, 在這個過程中可能會 有多個受信任的 CA 參與。其中, Root CA ⼜被稱為信任錨 (trust anchor), 除了 Root CA 外, 所有其它參與建立信任關係的 CA ⼜被稱為中繼 CA (intermediate CA), ⽽這段被建立起來的信任關係就稱為信任鍊 (chain of trust) 。 根憑證 (Root CA) 中繼憑證 (Intermediate CA) 中繼憑證 (Intermediate CA) 終端憑證 (Leaf CA)
- 17. 17 關於SSL/TLS的⼆三事 Chain of Trust 信任鍊如何被客⼾端驗證? • 下⾯這張圖描繪了 leaf, intermediate 以及 root certificate 如何彼此相連進⽽構 成信任鍊.
- 19. 19 Kubernetes ingress controller的範例 • 範例(3):是對反向代理SSL通信模型的”復現“，即client與ingress controller(nginx)間採⽤https加密通信，但ingress controller(nginx)與app3 間則是明文的http通信 • 為了讓ingress controller能夠進⾏SSL的通信握⼿, 必須要把SSL憑證上傳 進Kubernetes裡, 然後設定Ingress來使⽤ Internet https://app3.example.com https (443) Node Ingress: app3-ing nginx-ingress-controller app3- svc http (80) pod pod http (8080)
- 20. 20 使⽤Openssl創建⼀個根憑證(RootCA)公/私鑰 # Generate a CA private key openssl genrsa -out rootCA.key 2048 Generating RSA private key, 2048 bit long modulus .....................................+++++ ........................................................+++++ e is 65537 (0x10001) # Generate a CA public key openssl req -x509 -new -nodes -key rootCA.key -subj "/CN=example.com" -out rootCA.crt
- 21. 21 使⽤Openssl透過根憑證來派發self-signed憑證 步驟#1 • 創建⼀個證書簽發請求的設定檔server.csr.cnf [req] default_bits = 2048 prompt = no default_md = sha256 distinguished_name = dn [dn] C=TW ST=Taipei L=Taipei O=example OU=witlab emailAddress=admin@example.com CN = localhost
- 22. 22 使⽤Openssl透過根憑證來派發self-signed憑證 步驟#2 • 透過openssl來產⽣⼀個CSR (Certificate Signing Request) # Generate a CSR openssl req -new -sha256 -nodes -out server.csr -newkey rsa:2048 -keyout server.key -config <( cat server.csr.cnf )
- 23. 23 使⽤Openssl透過根憑證來派發self-signed憑證 步驟#3 • Chrome瀏覽器⾃版本58以要求SSL證書使⽤Subject Alternative Name (SAN) ⽽不是流⾏的Common Name (CN)，因此已移除了對CN⽀持。 如果您使 ⽤僅定義了CN的⾃簽名證書，則在使⽤⾃簽名證書調⽤網站時會出現如 下錯誤：
- 24. 24 使⽤Openssl透過根憑證來派發self-signed憑證 步驟#3 • 產⽣v3.ext的檔案 (這個檔案就是要⽤來設定在憑證裡的 Subject Alternative Name資訊) authorityKeyIdentifier=keyid,issuer basicConstraints=CA:FALSE keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment subjectAltName = @alt_names [alt_names] DNS.1 = localhost DNS.2 = app3.example.com
- 25. 25 使⽤Openssl透過根憑證來派發self-signed憑證 步驟#4 • 產⽣self-signed的憑證 openssl x509 -req -in server.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out server.crt -days 500 -sha256 -extfile v3.ext
- 27. 27 範例-Golang程式 (app3) 容器化 • 創建要容器化的描敘檔: Dockerfile
- 28. 28 範例-編譯Golang程式/容器化/上傳鏡像 • 切換到”app3”⽬錄, 透過make程式來編譯Golang程式/容器 化/上傳鏡像 make 記得修改 repos
- 29. 29 範例-編譯Golang程式/容器化/上傳鏡像 • 檢查編譯完的容器鏡像 • 檢查看是容器鏡像是否⼰經上傳到Docker Hub docker images | grep app3
- 32. 32 範例:將簽名密鑰以Secret的資源保存到Kubernetes kubectl create secret tls app3-tls-secret --cert=server.crt --key=server.key --namespace=default • Ingress controller會從Kubernetes的Secret資源中讀取要使 ⽤的憑證
- 34. 34 範例-在本機的Hosts檔裡增加名稱解析 • 由於Kubernetes的Ingress是透過hostname來將 外部的http/https的請求轉派到後端的服務 • 需要在本機的Host檔裡新增⼀筆資料來解析 測試⽤的hostname(FQDN)到本機的IP address Service App App App App Service Ingress Controller Pod Pod Pod Ingress sudo vi /etc/hosts
- 36. 36 範例-匯入ca.crt根憑證到瀏覽器憑證管理中 • 根據憑證Chain of Trust的原則, 我們只需要匯入根憑證 • 匯入rooCA.crt根憑證到瀏覽器憑證管理中, 並信任此根憑證 • 不同的作業系統的⽅式都不太⼀樣, 以下以Mac OS為例
- 38. 38 Reference • 实践kubernetes ingress controller的四个例⼦(Tony Bai) • https://tonybai.com/2018/06/21/kubernetes-ingress-controller- practice-using-four-examples/ • HTTPS服务的Kubernetes ingress配置实践 (Tony Bai) • https://tonybai.com/2018/06/25/the-kubernetes-ingress-practice-for- https-service/ • Fixing Chrome 58+ [missing_subjectAltName] with openssl when using self signed certificates • https://alexanderzeitler.com/articles/Fixing-Chrome- missing_subjectAltName-selfsigned-cert-openssl/
- 39. 39 Reference https://medium.com/@clu1022 • 那些關於SSL/TLS的⼆三事(⼀) — Why SSL/TLS? • 那些關於SSL/TLS的⼆三事(⼆) — How SSL works? • 那些關於SSL/TLS的⼆三事(三) —給誰簽? • 那些關於SSL/TLS的⼆三事(⼗⼆) — Chain of Trust