Let's Encrypt 的 ACMEv1 將在今年十一月進入日落階段

Let's Encrypt 推出 ACMEv2 後要終止 ACMEv1 的計畫,是今年三月發的消息,但一直沒注意到,剛剛翻到「acme-client(1) moves to Let's Encrypt v02 API」時才看到的:「End of Life Plan for ACMEv1」。

日落分成幾個階段,第一個階段是今年十一月終止透過 ACMEv1 註冊新帳號:

In November of 2019 we will stop allowing new account registrations through our ACMEv1 API endpoint. Existing accounts will continue to function normally.

第二個階段是明年六月終止透過 ACMEv1 申請新的 certificate:

In June of 2020 we will stop allowing new domains to validate via ACMEv1.

第三個階段是 2021 年會開始測試關閉 ACMEv1 的 renew 功能,一個月不會超過一次,每次大約 24 小時,這是讓 client 有機會丟出錯誤訊息:

Starting at the beginning of 2021 we will occasionally disable ACMEv1 issuance and renewal for periods of 24 hours, no more than once per month (OCSP service will not be affected).

最後的階段是 2021 年的六月,會完全關閉 ACMEv1 所有的服務:

In June of 2021 we will entirely disable ACMEv1 as a viable way to get a Let’s Encrypt certificate.

目前在用的都支援 ACMEv2 了,應該是 ok...

在 Amazon Aurora 利用 ProxySQL 的讀寫分離提昇效能

Percona 的「Leveraging ProxySQL with AWS Aurora to Improve Performance, Or How ProxySQL Out-performs Native Aurora Cluster Endpoints」這篇有夠長的,其實就是發現 AWSAmazon Aurora 只使用 Cluster Endpoint 無法壓榨出所有效能,只有當你讀寫分離拆開 Cluster endpoint 與 Reader endpoint 時才能提昇效能。主要是在推銷 ProxySQL 啦,其他的軟體應該也能達到類似的效果...

然後這張怪怪的,應該是 copy & paste 上去的關係?

因為事後再疊 ProxySQL 進去不會太困難,一般還是建議先直接用服務本身提供的 endpoint (少了一層要維護的設備),等到有遇到效能問題時再來看是卡在哪邊,如果是 R/W split 可以解決的,才用 ProxySQL 或是其他軟體來解...

AWS KMS 可以在 VPC 內直接存取了

AWS Key Management Service 宣布支援 AWS PrivateLink Endpoint 了:「How to Connect Directly to AWS Key Management Service from Amazon VPC by Using an AWS PrivateLink Endpoint」。先前需要透過 Internet 流量存取 (透過 NAT、Proxy 之類的服務),現在則是可以接到 VPC 內直接用了:

Previously, applications running inside a VPC required internet access to connect to AWS KMS. This meant managing internet connectivity through internet gateways, Network Address Translation (NAT) devices, or firewall proxies.

With support for Amazon VPC endpoints, you can now keep all traffic between your VPC and AWS KMS within the AWS network and avoid management of internet connectivity.

KMS 需要 Internet 也是之前設計架構時比較痛的地方,現在總算是有個方向可以減少痛處了...

Amazon CloudWatch Logs 換 SSL Certificate 的 CA

收到標題是「Upcoming Changes to SSL Certificates in Amazon CloudWatch Logs」的信件,說明 Amazon CloudWatch Logs 要換 SSL Certificate 的 CA,看起來是要換成自家的:

We will be updating the certificate authority (CA) for the certificates used by Amazon CloudWatch Logs domain(s), between 8 January 2018 and 22 January 2018. After the updates complete, the SSL/TLS certificates used by Amazon CloudWatch Logs will be issued by Amazon Trust Services (ATS), the same certificate authority (CA) used by AWS Certificate Manager.

然後有提到 cross-sign 的部份,有透過 Starfield 的 Root CA 簽,所以只要下面有任何一個有在 Root CA store 裡面就應該會信任:

The update means that customers accessing AWS webpages via HTTPS (for example, the Amazon CloudWatch Console, customer portal, or homepage) or accessing Amazon CloudWatch Logs API endpoints, whether through browsers or programmatically, will need to update the trusted CA list on their client machines if they do not already support any of the following CAs:
- "Amazon Root CA 1"
- "Starfield Services Root Certificate Authority - G2"
- "Starfield Class 2 Certification Authority"

另外條列出有哪些 API endpoint 會改變:

This upgrade notice covers the following endpoints:
logs.ap-northeast-1.amazonaws.com
logs.ap-northeast-2.amazonaws.com
logs.ap-south-1.amazonaws.com
logs.ap-southeast-1.amazonaws.com
logs.ap-southeast-2.amazonaws.com
logs.ca-central-1.amazonaws.com
logs.eu-central-1.amazonaws.com
logs.eu-west-1.amazonaws.com
logs.eu-west-2.amazonaws.com
logs.eu-west-3.amazonaws.com
logs.us-east-1.amazonaws.com
logs.us-east-2.amazonaws.com
logs.us-west-1.amazonaws.com
logs.us-west-2.amazonaws.com
logs.sa-east-1.amazonaws.com

然後也列出了有哪些系統「應該」會支援:

* Operating Systems With ATS Support
- Microsoft Windows versions that have January 2005 or later updates installed, Windows Vista, Windows 7, Windows Server 2008, and newer versions
- Mac OS X 10.4 with Java for Mac OS X 10.4 Release 5, Mac OS X 10.5 and newer versions
- Red Hat Enterprise Linux 5 (March 2007), Linux 6, and Linux 7 and CentOS 5, CentOS 6, and CentOS 7
- Ubuntu 8.10
- Debian 5.0
- Amazon Linux (all versions)
- Java 1.4.2_12, Java 5 update 2, and all newer versions, including Java 6, Java 7, and Java 8

不過沒看到 Windows XP 耶,不知道是怎樣 XD

Amazon API Gateway 可以透過 NLB 接進 VPC 內了

AWS 宣佈可以透過 Network Load BalancerAPI Gateway 接進 VPC 內了:「Amazon API Gateway Supports Endpoint Integrations with Private VPCs」。

You can use API Gateway to create an API endpoint that is integrated with your VPC. You create an endpoint to your VPC by setting up a VPC link between your VPC and a Network Load Balancer (NLB), which is provided by Elastic Load Balancing.

基本上是所有的區域都有了,除了美國政府的區域外:

This feature is now available in US East (N. Virginia), US East (Ohio), US West (Oregon), US West (N. California), Canada (Central), South America (São Paulo), EU (Ireland), EU (Frankfurt), EU (London), Asia Pacific (Singapore), Asia Pacific (Tokyo), Asia Pacific (Sydney), Asia Pacific (Seoul), and Asia Pacific (Mumbai) AWS regions.

是透過 NLB 接進去,而不是 ELB Classic 或是 ALB,可以來想像網路架構是怎麼做的...

AWS PrivateLink + SaaS 的用法

原來 AWS 搞 PrivateLink 不只要整合自己的服務,還包括非 AWS 的服務:「AWS PrivateLink Update – VPC Endpoints for Your Own Applications & Services」。

簡略的來說,以往的 SaaS 服務大多都是提供 Public IP 讓客戶端使用,對於服務的使用方與提供方來說,當兩者都在 AWS 同一個 region 時,在處理 security group 設定不太方便,所以通常就不會設定... 另外還要注意可以從外部透過 access token 存取服務 (像是有員工離職,但 access token 未必會換掉)。

這次推出的 PrivateLink + SaaS 的組合提供了另外一個選擇,可以把服務藏在內部,安全性比以前好很多:

Today we are building upon the initial launch and extending the PrivateLink model, allowing you to set up and use VPC Endpoints to access your own services and those made available by others.

不過這個機制綁 AWS 綁的更深了...

AWS PrivateLink

AWS 計畫把先前設計的 VPC Endpoint 都併到 AWS PrivateLink 裡,統一管理:「New – AWS PrivateLink for AWS Services: Kinesis, Service Catalog, EC2 Systems Manager, Amazon EC2 APIs, and ELB APIs in your VPC」。

Today we are announcing AWS PrivateLink, the newest generation of VPC Endpoints which is designed for customers to access AWS services in a highly available and scalable manner, while keeping all the traffic within the AWS network. Kinesis, Service Catalog, Amazon EC2, EC2 Systems Manager (SSM), and Elastic Load Balancing (ELB) APIs are now available to use inside your VPC, with support for more services coming soon such as Key Management Service (KMS) and Amazon Cloudwatch.

這樣就不用弄 proxy server 然後在上面管一堆 policy 了... (先不講自己搞 HA 的麻煩事,光是有些程式還得 patch 才能支援 proxy 就會想翻桌了 XD)

Amazon API Gateway 可以獨立運作了...

Amazon API Gateway 先前一定要跟 Amazon CloudFront 綁在一起 (而且還是很奇怪的 distribution,不是 Price Class 裡面任何一種分類),現在總算可以獨立自己運作了:「Amazon API Gateway Supports Regional API Endpoints」。

A regional API endpoint is a new type of endpoint that is accessed from the same AWS region in which your REST API is deployed. This helps you reduce request latency when API requests originate from the same region as your REST API.

而且這樣一來,如果還是要用 Amazon CloudFront 擋在前面的話,可以自己選擇 Price Class:

Additionally, you can now choose to associate your own Amazon CloudFront distribution with the regional API endpoint.

以前用起來頗莫名其妙的 XDDD

DynamoDB 也可以透過 VPC Endpoint 存取了

Amazon DynamoDB 也可以透過 VPC Endpoint 存取了:「New – VPC Endpoints for DynamoDB」。

這樣一來,除了 Amazon S3 可以在 private network 內存取外,DynamoDB 也可以直接存取了...

VPC Endpoint 主要是解決對於安全性與頻寬的需求,不過什麼時候會出一般性的 VPC Endpoint 啊,而非個別服務個別設計打洞...

Let's Encrypt 決定要規劃 Wildcard SSL Certificate 了

Let's Encrypt 把時間表喊出來了,預定在 2018 年年初開放使用:「Wildcard Certificates Coming January 2018」。

Wildcard SSL Certificate 會需要走新的 ACME v2 協定認證:

Wildcard certificates will be offered free of charge via our upcoming ACME v2 API endpoint. We will initially only support base domain validation via DNS for wildcard certificates, but may explore additional validation options over time.

跟前陣子提到的「ACME v2 API Endpoint Coming January 2018」是相同的時間。

這好讚...