AWS 的 VPC 開放自訂 IPv6 CIDR 了,但還是有 4 的倍數的限制...

AWS 的公告,VPC 裡的 IPv6 可以自訂 CIDR 了:「VPCs and subnets now support more sizes for IPv6 CIDRs」。

不過還是有限制,首先是 VPC 的大小必須是 /44/60 中 4 的倍數,也就是只有 /44/48/52/56 以及 /60 這五個可以用,而 subnet 也有類似的限制,但從 /44/64,所以剛好就是多了 /64 可以用:

Amazon VPC allows customers to create VPCs and subnets of different sizes using IPv6 CIDRs. With this capability, customers can now create VPCs in sizes between /44 and /60, and subnets in sizes between /44 and /64, in increments of /4.

先前的限制是 VPC 只能給 /56 以及 subnet 只能給 /64 的搭配,是個「可以動」但總是覺得「...」的設計:

Before today, AWS supported one standard IPv6 CIDR block size of /56 for VPC and /64 for subnet, whereas IPv4 CIDR block size were flexible for both VPCs and subnets.

不過我實際在 ap-northeast-1 上測試,發現如果是 AWS 發的 IPv6 address,固定就是 /56 的大小,然後 subnet 在選擇的時候可以選 /56/60/64

這邊提到 VPC 可以選擇大小,應該是其他方式帶進來的 IPv6 address?

另外這次的 /4 的遞增限制,我猜是 AWS 裡面 SDN 上面的限制?IPv4 的 CIDR 有 33 個大小 (/0/32),IPv6 上面如果也處理 33 個的話,反過來設計剛好是 /4 遞增的 workaround?

不過話說回來,我記得前陣子 AWS 公佈要收 Public IPv4 address 的費用時 (參考「AWS 將開始收取 IPv4 的 Public IP 費用」),Hacker News 上有人抱怨還是有很多 AWS 的服務是 IPv4 only,在純 IPv6 network 上面是不太會動的;把這些服務的 IPv6 endpoint 生出來應該要趕快放到 roadmap 上...

AWS 東京區的機器有 μs 等級的 Amazon Time Sync Service 可以用

AWS 宣佈 μs 等級的 Amazon Time Sync Service,也就是比 ms 再多三個零的等級:「Amazon Time Sync Service now supports microsecond-accurate time」。

一般的 Time Sync Service 服務大多是 ms 等級,也就是 10-3 秒這個等級,μs 則是到了 10-6...

但這其實有點詭異,目前只有 AWS 東京區有這個服務,而且限制在 r7g 的機器上才能用:

Amazon Time Sync with microsecond-accurate time is available starting today in the Asia Pacific (Tokyo) Region on all R7g instances, and we will be expanding support to additional AWS Regions and EC2 Instance types.

也就是說 us-east-1us-west-2 這些第一線熱門的區域沒有,另外只有特別的 ARM 機種,而且是 memory-intensive 的 r7g 才能用?

先放著看看 XDDD

Amazon EBS 在 Compliance mode 下的 Snapshot Lock

Jeff Barr 寫了「New – Amazon EBS Snapshot Lock」這篇,介紹 Amazon EBS 的新功能 Snapshot Lock。

從名字就知道是鎖住 snapshot 不讓人刪除,比較特別的是有兩個模式,第一個是 Governance,這個模式下就只是防止誤刪除的情況:

This mode protects snapshots from deletions by all users. However, with the proper IAM permissions, the lock duration can be extended or shortened, the lock can be deleted, and the mode can be changed from Governance mode to Compliance mode.

比較重要的是第二個模式 Compliance,在超過猶豫期 (cooling-off period) 後就不能動了,就算你有最大的權限 (我猜是連 root account 也不能動),唯一能操作的只有延長 lock 時間:

This mode protects snapshots from actions by the root user and all IAM users. After a cooling-off period of up to 72 hours, neither the snapshot nor the lock can be deleted until the lock duration expires, and the mode cannot be changed. With the proper IAM permissions the lock duration can be extended, but it cannot be shortened.

的確是遵循法規用的功能...

AWS 宣布 EKS 支援期從 14 個月變成 26 個月

有訂 RSS feed 但應該是漏看了,後來在 X (Twitter) 上看到 qrtt1 轉貼 ingramchen 的貼文才注意到的,AWS 宣布 EKS 支援期從本來的 14 個月 (跟 k8s 官方相同) 變成 26 個月 (多了一年):

公告在「Amazon EKS Extended support for Kubernetes Versions now available in preview」以及「Amazon EKS extended support for Kubernetes versions available in preview」這邊。

這邊查了資料發現有點複雜,KEP-2572: Defining the Kubernetes Release Cadence 這邊有正式的說明,但「Kubernetes | endoflife.date」這邊比較清楚 14 個月是怎麼來的:

Kubernetes follows an N-2 support policy (meaning that the 3 most recent minor versions receive security and bug fixes) along with a 15-week release cycle. This results in a release being supported for 14 months (12 months of support and 2 months of upgrade period).

雖然是付費功能,但目前這個功能是 preview,代表不受到 SLA 之類的保障,應該是之後成熟了再看情況變成 GA:

Today, we’re announcing the preview of Amazon Elastic Kubernetes Service (EKS) extended support for Kubernetes versions. You can now run Amazon EKS clusters on a Kubernetes version for up to 26 months from the time the version is generally available on Amazon EKS. Extended Support is available as a free preview for all Amazon EKS customers, starting today with Kubernetes version 1.23.

算是還不錯的消息?就目前看到的經驗,每次的升級都會爛掉不少東西,所以沒用到新功能卻被迫要更新的次數可以降低一些,總是好事...

Google SRE 團隊整理出過去二十年的十一條心得

Google 的 SRE 團隊整理出過去二十年的心得,當看故事的心態在看的:「Lessons Learned from Twenty Years of Site Reliability Engineering」,在 Hacker News 上也有討論:「Lessons Learned from Twenty Years of Site Reliability Engineering (sre.google)」。

裡面的項目大多都會在公司成長時不斷的導入,都是夠大就會遇到的。

比較有趣的是第六條,這是唯一一條全部都用大寫字母列出來的:

COMMUNICATION CHANNELS! AND BACKUP CHANNELS!! AND BACKUPS FOR THOSE BACKUP CHANNELS!!!

到 Google 這個規模的架構,這邊就會規劃找完全獨立於 Google 架構的方案來用;我猜應該是傳統的 colocation 機房 (像是 AT&T 之類的),上面跑 IRC server 之類的?

在 Hacker News 上面也有其他人提到 Netflix 也有類似的規劃,需要有一個備援的管道是完全獨立於 AWS 的;另外同一則 comment 裡也有提到 Reddit 的作法是在辦公室裡面放 IRC server 備援:

Yes! At Netflix, when we picked vendors for systems that we used during an outage, we always had to make sure they were not on AWS. At reddit we had a server in the office with a backup IRC server in case the main one we used was unavailable.

IRC 還是很好用的 XD

Oxide 推出的 Oxide Cloud Computer

Hacker News 上看到「The Cloud Computer」這篇行銷新聞稿被衝了很高,翻了一下討論「Oxide: The Cloud Computer (oxide.computer)」,裡面看到不少有趣的東西。

行銷新聞稿裡面包裝的很「行銷」,如果看完後可以理解 Oxide Cloud Computer 其實就是賣機櫃,裡面包好一個 mini AWS 需要的硬體與軟體。

這個機櫃裡的硬體部分可以在「Specifications」這邊看到,裡面有主機、網路與電供這些東西,而且照他提到的 60cm * 106cm 的佔地面積需要 1145kg,一般辦公建築物沒辦法直接放,需要用架高地板的方式把重量打散掉,而且放好幾台的時候應該需要找結構工程師重新計算安全性;如果是機房的話應該是有機會直接塞進去 (因為前面的事情都先考慮過了)。

軟體的部分則是在 id=38024259 裡面看到的,上面是用 Illumos 當作 hypervisor,這是 OpenSolaris 的 fork,這個選擇還蠻特別的,不是選 Linux-based 的系統來包,不確定是不是考慮到 license 的問題:

The hypervisor OS is based on Illumos, which was forked from OpenSolaris, and it uses Bhyve from FreeBSD for virtualization.

另外在 id=38026273 這邊也有一些解讀,可以了解 Oxide 在 Illumos 上面重新實作了 OpenStack 的功能 (也可以看做 mini AWS):

Oh. I get what this is. It's a "cloud" mainframe. They're trying to be the Apple of mainframes.

Reinvent OpenStack, slap it on some 8Us and storage arrays, shove it in a rack, and ship it to a colo with a professional installer. So basically one of the larger server vendors but with integrated "cloud" software, minus the 2-hour service turnaround and spare parts.

The fact that they're writing the software from scratch is going to add years of lead time until they reach parity with other solutions. My guess is they're hoping they can get sticker price or TCO low enough that it outweighs the lack of functionality and uncertainty of a brand new everything. If you just need some VMs in a lab in the office closet, might work.

可以想到的 TA... 馬上可以想到的是,需要把資料都控制在自家的公司 (像是金融法規/軍方/TSMC/...),這些公司在這之前的路線會是買硬體後上 VMwareCitrix 或是 OpenStack 之類的方案,這些方案除了可以自己養人,應該也都有 SI 可以付費代操。而 Oxide 這次給出來的方案則是都包掉?不過 SI 也可以去包 bare-metal server 來賣就是了...

其他的暫時想不到,畢竟 ecosystem 還是很重要,Oxide 推出的東西沒有特別吸引人的地方,也許看看還能怎麼包裝跟想像?

AWS 要在歐洲建立一個完全獨立的 Cloud 系統

CNBC 上看到的新聞,AWS 打算在歐洲建立一個完全獨立的 Cloud 系統:「Amazon launches European ‘sovereign’ cloud as EU data debate rages」。

AWS European Sovereign Cloud 會是完全獨立的 cloud:

Amazon on Wednesday said it will launch an independent cloud for Europe aimed at companies in highly-regulated industries and the public sector.

這邊講的「完全獨立」,除了東西都放在歐洲以外,連員工都是歐盟員工:

Customers of the new system will be able to keep certain data in the European Union and only EU-resident AWS employees who are located in the 27-nation bloc will have control of the operations and support for the sovereign cloud.

這個作法倒是頗特別的,看起來是想要試著說服歐盟這樣是 OK 的?推出的時候可以看看還有什麼特別的東西?

Amazon RDS 的 TLS 連線所使用的 CA 要更新了

Amazon RDSTLS (SSL) 連線所使用的 CA 要更新了:「Rotate Your SSL/TLS Certificates Now – Amazon RDS and Amazon Aurora Expire in 2024」。

如果沒有開 TLS 連線的話是不受影響 (像是內網裸奔),但如果有在用 TLS 的話就要注意一下了,看起來得手動更新處理。

比較特別的是新的 CA 簽的超長:

Most SSL/TLS certificates (rds-ca-2019) for your DB instances will expire in 2024 after the certificate update in 2020. In December 2022, we released new CA certificates that are valid for 40 years (rds-ca-rsa2048-g1) and 100 years (rds-ca-rsa4096-g1 and rds-ca-ecc384-g1). So, if you rotate your CA certificates, you don’t need to do It again for a long time.

現有的 rds-ca-2019 可以在 https://s3.amazonaws.com/rds-downloads/rds-ca-2019-root.pem 這邊取得,用 openssl x509 -in rds-ca-2019-root.pem -text 可以看到資料。

crt.sh 上翻過一些字串,沒看到被簽的記錄,所以看起來無法透過一般 trusted store 裡面的 Root CA 一路信任下來。

新的 key 應該也是 Private Root CA,從名字看起來應該是對應的 key algorithm。其中 RSA 2048 的簽了 40 年,而 RSA 4096 與 ECC 384 的簽了 100 年,雖然說是自家弄的 CA,但目前的 compliance 沒有要求 key rotation 嗎...

Anyway,常用的區域基本上都是 August 22, 2024 這個日期,大約還有九個多月的時間更新,依照 AWS 的慣例,後面應該還會提醒幾次:

話說 2020 年的時候也有更新,當時是 Jeff Barr 出來說明的:「Urgent & Important – Rotate Your Amazon RDS, Aurora, and Amazon DocumentDB (with MongoDB compatibility) Certificates」,現在看起來一些常態性的說明都陸續交棒給 Channy Yun 了...

不過這次這樣搞 40 年 & 100 年,後續要更新應該都是演算法的推進了,比較不會是要到期...

Cavium (被 Marvell 併購) 在 Snowden leak 中被列為 SIGINT "enabled" vendor

標題可能會有點難懂,比較簡單的意思就是在 Snowden 當年 (2013) 洩漏的資料裡面發現了不太妙的東西,發現 Cavium (現在的 Marvell) 的 CPU 有可能被埋入後門,而他們家的產品被一堆廠商提供的「資安產品」使用。

出自 X (Twitter) 上面提到的:

這段出可以從 2022 年的「Communication in a world of pervasive surveillance」這份文件裡面找到,就在他寫的 page 71 (PDF 的 page 90) 的 note 21:

While working on documents in the Snowden archive the thesis author learned that an American fabless semiconductor CPU vendor named Cavium is listed as a successful SIGINT "enabled" CPU vendor. By chance this was the same CPU present in the thesis author’s Internet router (UniFi USG3). The entire Snowden archive should be open for academic researchers to better understand more of the history of such behavior.

Ubiquiti 直接中槍...

而另一方面,在 Hacker News 上的討論「Snowden leak: Cavium networking hardware may contain NSA backdoor (twitter.com/matthew_d_green)」就讓人頭更痛了,像是當初 Cavium 就有發過新聞稿提到他們是 AWS CloudHSM 的供應商:「Cavium's LiquidSecurity® HSM Enables Hybrid Cloud Users to Synchronize Keys Between AWS CloudHSM and Private Clouds」。

而使用者也確認有從 log 裡面看到看到 Cavium 的記錄:

Ayup. We use AWS CloudHSM to hold our private signing keys for deploying field upgrades to our hardware. And when we break the CI scripts I see Cavium in the AWS logs.

Now I gotta take this to our security team and figure out what to do.

居然是 CloudHSM 這種在架構上幾乎是放在 root of trust 上的東西...