認證(AuthN)與授權(AuthZ)

在Day 4的時候，筆者說明過有關於使用API Key的方式來保護後端API Provider的方式。同樣的也在Day 16的時候，透過觀測的方式確認，將未經授權請求給阻擋了下來，那是一個十分經典透過API Gateway保護的範例。

原本的故事是一個簡單的情境，那就是透過一個API Gateway將一個API保護起來，如此的單純造就了快樂的資訊團隊....工作哪有可能這麼美。

讓我們從新的一天開始來面對新的挑戰，開始吧。

故事：新增後端API 與新的消費者

同樣的，Sam正在快樂的享受當天早上沖泡好的新鮮烘焙咖啡，這時Aries過來跟他討論一個kong上面設定的問題。

Aries： 這次後端開發人員又新增了一個新的API，是一個全新的點子，而且已經有合作對象了，因此我有一個新的任務，那就是將這些正確的設定在kong上面，讓這些流量可以正確的被導引。不過我對於kong 的設定還沒有非常熟悉，所以想找你一起討論看如何設定才是正確。

Sam： OK阿，所以後端API 服務都已經設定好了對嗎？就等著流量過去而已？

Aries： 沒錯，我已經將設定基本上完成，不過還沒有sync到測試環境的kong讓新的合作對象測試使用。

Sam： 那讓我來看看你的設定....喔有些地方可能要調整一下，我來跟你說明認證與授權之間的關係。

個案討論：

這次的示範個案在 ironman2025\case_ELK_JPG_AuthZN 資料夾下，讀者如果有興趣可以一起開來看，下面這邊先討論有關設定中的一些內容，可以參考到 ironman2025\case_ELK_JPG_AuthZN\1.Kong_declarative\declarative\kong.yml，但在看yaml之前請先關注圖18-1，筆者先說明這次設定的一些相對關係。

圖18-1 Kong API Consumer 關係圖

圖18-1可以看到，後端有兩個API Provider提供服務，分別是：

• case_elk_jpg_authzn
  • port:8080
  • 透過 /weatherforecast 取得未來七天溫度及體感
• case_elk_jpg_authzn_weather
  • port:8080
  • 透過 /yyyy-MM-dd 取得指定日期天氣預報

另外就是對象要新增，因此可以看到在原有的consumer下，又新增了一位名為user2@user.com，且持有的key也設定完成。

上面這些說明，同樣的也被體現到了kong.yml的設定檔中，如下：

- name: case_ELK_JPG_AuthZN
  url: http://case_ELK_JPG_AuthZN:8080
  routes:
  - name: case_ELK_JPG_AuthZN
    paths:
    - /case_ELK_JPG_AuthZN/
    plugins:
    ...省略...
    - name: key-auth
      config:
        key_names:
        - apikey
        hide_credentials: false
- name: case_ELK_JPG_AuthZN_weather
  url: http://case_ELK_JPG_AuthZN_weather:8080
  routes:
  - name: case_ELK_JPG_AuthZN_weather
    paths:
    - /case_ELK_JPG_AuthZN_weather/
    plugins:
    ...省略...
    - name: key-auth
      config:
        key_names:
        - apikey
        hide_credentials: false

....中間省略..

consumers:
- username: user1@user.com
  custom_id: user1
  keyauth_credentials:
  - key: user1-api-key
- username: user2@user.com
  custom_id: user2
  keyauth_credentials:
  - key: user2-api-key

Sam： 這樣的設定僅有做到認證，沒有做到授權的設定喔！

Aries： 我在設定的時候也老覺得哪裡怪怪的，但對kong還不是很熟悉，所以想說同步到測試之前先找你討論看看。

Sam： 沒關係，先同步上去，做個實驗給你看你就知道我說甚麼了。

僅有認證(AuthN)的實驗

筆者這次還是使用postman做示範，首先先確定api provider都已經被正確的保護，因此對kong先發出兩個請求，而且都不帶apikey。所以預期回應應該會得到兩個401的回應，而且都是kong阻擋下來的。

圖18-2 第一個401

圖18-3 第二個401

接下來，就是著都帶第一位消費者的key發出請求(user1-api-key)，會發現都成功回應了。

圖18-4 API 1成功回應

圖18-5 API 2 成功回應

第二位消費者的就不特別列圖，直接使用kibana來確認整個請求的過程，會發現到只要認證有通過，不論是哪一位consumer都會成功的發出到任何一個API的請求。

圖18-6 Kibana的歷程

Kong 的授權 - ACL Plugin

Sam： 有注意到嗎？這樣設定雖說兩位consumer都可以正常使用，但是如果我們的API並不希望被這樣共用下，這樣的設定方式就可能會造成漏洞。這也就是OWASP API Security TOP 10的Security Misconfiguration，這代表著錯誤的設定方式造成了預期以外的請求許可行為。

Aries： 那kong在這一段要怎麼做？我還有看到很多的plugin，是其中一個plugin嗎？

Sam： 你說的沒錯，可以關注到ACL這個plugin，你可以搭配著apikey的認證方式嘗試看看。反正距離提供服務還有一點時間，測試環境就是給你用來測試用的，玩看看。晚一點我們再來看一下你研究的成果。

Aries： 好，那我試試看，感謝啦。

小結

就跟今天最前面說的一樣，企業中對於各式各樣的需求可能非常的複雜，因此在建立任何的管理設定時，需要考量的長久的管理問題。如果今天故事中的角色急就章的僅有將認證方式設定上去，確認了新的合作對象可以使用api後就草草了事。在越來越多的服務與合作對象被設定上去之後，可能在未來的某一天就會有意外開始爆發出來。

今天先將問題點出，明天筆者將解答要如何處理kong中授權的處理方式，讓我們明天見。