Kubernetes コントロールプレーンのアップグレードは、長い間、一度行うと元に戻せないものでした。オープンソースの Kubernetes はコントロールプレーンのロールバックをサポートしていないため、一度アップグレードしたら後戻りはできません。コミュニティはここまで大きな進歩を遂げており、 KEP-4330 ではロールバックを容易にするためにエミュレートされたバージョンが導入されています。しかし実際には、この制約により、組織はベイク期間、スタッガーグループ、自動サインオフ、数か月にわたるアップグレードサイクルなど、精巧な補償メカニズムを構築する必要に迫られています。Kubernetes は年に 3 つのマイナーバージョンをリリースしているため、特に規制の厳しい環境では、何百ものクラスターを管理しているチームは、何か問題が発生した場合に回復できる自信がないために、アップグレードを完全に延期することがよくあります。その結果、クラスターは古いバージョンで行き詰まり、セキュリティパッチが適用されず、最終的にはサポート期間の延長に直面することになります。 2026 年 7 月 1 日、 Amazon Elastic Kubernetes Service (Amazon EKS) の Kubernetes バージョンロールバック についてお知らせします。これは、クラスター管理者がクラスターのアップグレードを実行する際のセーフティネットを提供する新機能です。バージョンロールバックを使用すると、アップグレード後に問題が発生した場合に 7 日以内に Kubernetes バージョンのアップグレードを取り消して、クラスターを以前の動作状態に戻すことができます。 エミュレートされたバージョンのようなアプローチではクラスターが過渡的な保持状態に保たれるのに対し、EKS バージョンロールバックはクラスターをエミュレートしたものではなく、本番環境で実行されていた完全に検証済みの以前のバージョンに戻します。これで、クラスターを例えば Kubernetes 1.34 から 1.35 にアップグレードして互換性の問題が見つかった場合、7 日以内に 1.34 にロールバックできます。クラスターを再構築したり、プレッシャーのかかる状況でトラブルシューティングを急いだりする必要はありません。Kubernetes のバージョンアップグレードの [元に戻す] ボタンと考えてください。 この機能は、EKS がアップグレードに使用するのと同じインクリメンタルアプローチに合わせて、一度に 1 つのマイナーバージョンにロールバックすることをサポートします。また、安全にロールバックできるように、EKS は クラスターインサイト を通じてクラスターのロールバック準備状況を自動的に評価し、処理を進める前にノードバージョンの互換性やアドオンの依存関係などの項目にフラグを付けます。状況をすでに評価していて、迅速に行動したい場合は、 --force フラグを使用してこれらのチェックをバイパスできます。上記は、独自のノードを管理する場合でも、AWS に処理させる場合でも、すべての EKS クラスターに適用されます。しかし、フルマネージドインフラストラクチャを採用しているお客様にとっては、ロールバックはさらに一歩進んだものです。 EKS Auto Mode のロールバック EKS Auto Mode では、本番環境に対応した Kubernetes クラスターをワンクリックでデプロイし、コンピューティング、ネットワーキング、ストレージの管理を自動化できるため、インフラストラクチャではなくアプリケーションに集中できます。EKS Auto Mode では、コントロールプレーンとマネージドノードの両方を同時にロールバックする必要があるため、 バージョンロールバック に関する追加の考慮事項があります。ノードのロールバックはポッドの中断バジェットを考慮しているため、設定によってはプロセスに時間がかかる場合があります。 このプロセスを制御できるように、どの時点でもノードのロールバックを停止できる キャンセル API を導入しました。ロールバックに時間がかかりすぎると判断した場合、またはアプローチを変更したい場合は、キャンセルして中断バジェットを調整して物事を加速させるか、別の今後の進め方を選択することができます。 デフォルトでは、EKS はワークロードの安定性を優先するため、ロールバック中に中断バジェットをバイパスすることはありません。必要に応じていつでも中断バジェットを自分で変更したり削除したりして、プロセスをスピードアップできます。 試してみましょう バージョンロールバックを試すために、Amazon EKS コンソールに移動し、最近アップグレードした私のクラスターの 1 つを選択しました。 クラスターの設定ページから、バージョンロールバックを開始するオプションと、現在のロールバックウィンドウに関する情報が表示されます。 ロールバックを開始する前に、ロールバックのインサイトを確認して、潜在的な問題がないかどうかを確認しました。インサイトにより、私のノードの状態がわかり、先に進む前に対処すべき点にフラグが付けられました。 確認後、ロールバックが開始されました。私のクラスターはプロセス全体を通して機能し続けました。コントロールプレーンのロールバックには、標準のアップグレードと同様に約 20 分かかりました。私の EKS Auto Mode クラスターでは、中断バジェット設定に従ってノードが正常にロールバックされました。 完了すると、私のクラスターは前の Kubernetes バージョンに戻り、期待どおりに動作しました。 今すぐご利用いただけます Amazon EKS の Kubernetes バージョンロールバック は、Amazon EKS が利用可能なすべての商用 AWS リージョンで、追加料金なしで今すぐご利用いただけます。通常発生する標準の EKS とコンピューティングコストのみをお支払いいただきます。ロールバック機能を使用しても、追加料金は発生しません。 コントロールプレーンのロールバックはすべての EKS クラスターで使用でき、ノードのロールバックは EKS Auto Mode を実行しているクラスターで使用できます。バージョンロールバックは、EKS 標準サポートと延長サポートで利用可能な Kubernetes バージョンを実行しているクラスターをサポートします。 開始するには、 Amazon EKS のドキュメント を参照するか、 Amazon EKS コンソール で直接試してみてください。 原文は こちら です。

アプリケーションの TLS 証明書を管理している場合、証明書が期限切れになると、顧客にエラーが表示されるか、サービスが停止するという課題をご存知だと思います。証明書の有効期間が短くなるにつれて（ 認証局 (CA)/ブラウザフォーラム により、最大有効期間を 2027 年 3 月から 100 日間に短縮し、2029 年までに 47 日に短縮することが義務付けられています)、手動更新プロセスは受け入れられなくなります。自動化が必要です。 自動証明書管理環境 (ACME) は、人間の介入なしで TLS 証明書をリクエスト、更新、および取り消すためのオープンプロトコルです。Let’s Encrypt と同じプロトコルであり、あらゆるプラットフォームで数十のクライアントによってサポートされています。 2026 年 6 月 30 日、 AWS Certificate Manager (ACM) でのパブリック証明書の ACME サポートについてお知らせします。ACM では、 Certbot 、 Kubernetes の証明書マネージャー 、 acme.sh 、または既に使用しているその他のクライアントなど、ACMEv2 互換のクライアントならどれでも動作するフルマネージド ACME サーバーエンドポイントが提供されるようになりました。標準の ACME プロトコルを使用して、 Amazon Trust Services からパブリック TLS 証明書を発行できます。 これまで、ACME プロトコルを使用した自動化された証明書管理を希望していた場合、ACM に加えて外部の認証局に頼っていたため、可視性が断片化されていました。ACM に保存されていた証明書もあれば、中央ダッシュボードなしで外部で管理されていた証明書もあります。PKI 管理者は、誰が証明書をリクエストできるか、またどのドメインが許可されるかを制御することができませんでした。 ACM の ACME サポートにより、1 つ以上のマネージド ACME エンドポイントをセットアップして、組織全体の ACME 証明書の使用状況を一元的に管理および監視できるようになりました。 PKI 管理者として、お客様は基本的な証明書発行に留まらない一元的な管理が可能になります。IAM ロールを ACME アカウントにバインドすることで、各クライアントがどのドメインをリクエストできるかをきめ細かく制御できます。エンドポイントレベルでドメインスコープを定義して、組織全体のポリシーを適用できます。また、一元的なモニタリングと可視化を同じ場所で行うことができます。 AWS CloudTrail はすべての証明書リクエストを監査できるようにログに記録し、 Amazon CloudWatch は運用メトリクスを追跡し、ACM は証明書の更新が近づくと有効期限通知を送信します。ACM を使用すると、PKI チームは ACM コンソール、API コール、ACME のいずれで発行された証明書であっても、すべての証明書を検索できます。 仕組み 開始するには、まず専用の ACME エンドポイントをセットアップし、外部アカウントバインディング (EAB) を使用して認証制御を設定し、エンドポイントが証明書を発行できるドメインを検証し、既存の ACME クライアントを新しいエンドポイントにポイントします。 ドメイン認証ステップは重要です。これにより、証明書の発行をセットアップできる者と証明書をリクエストできる者が区別されます。PKI 管理者は、管理者が保持している DNS 認証情報を使用して、エンドポイントレベルでドメインを 1 回検証します。証明書を必要とするアプリケーション所有者は DNS に触れることはありません。彼らは EAB 認証情報を使用して登録し、エンドポイントはリクエストを許可するドメインとスコープを適用します。つまり、DNS キーを一緒に配布しなくても、証明書の自動化を組織全体に広く配布できるということです。 このデモを、AWS Certificate Manager コンソールの [ ACME 証明書 ] ページから開始します。 このアカウントには既にいくつかのエンドポイントと証明書があります。新しいエンドポイントと証明書を最初から作成する手順を説明します。まず、[ ACME エンドポイントの作成 ] を選択します。 エンドポイントに名前を付けます。[ エンドポイントタイプ ] は [ パブリック ] です。ACME クライアントはパブリックインターネット経由で接続します。[ 証明書タイプ ] は [ パブリック ] です。証明書は Amazon Trust Services によって発行され、ブラウザとオペレーティングシステムによってデフォルトで信頼されます。証明書キータイプでは、デフォルトの ECDSA P-256 のままにします。RSA 2048 と ECDSA P-384 は、クライアントが必要とする場合にも使用できます。 下にスクロールして、ドメインを設定します。ドメイン名を入力し、ドメインスコープを選択します。スコープは、ACME クライアントがこのドメインに対してどの証明書パターンをリクエストできるかを正確に制御します。[ 完全一致ドメイン ] のみをチェックすると、クライアントはその特定のドメイン名の証明書のみをリクエストできます。[ サブドメイン ] を追加すると、どのサブドメイン (api.example.com や dev.example.com など) の証明書も許可されます。[ ワイルドカード ] を追加すると、ワイルドカード証明書 (*.example.com) が許可されます。スコープのチェックをオフのままにしておくと、ACME リクエストが有効であっても、このエンドポイントを使用するクライアントはそのタイプの証明書をリクエストできなくなります。本番環境のエンドポイントでは、厳密なセキュリティ体制を適用するために、[ 完全一致ドメイン ] と [ サブドメイン ] のみを有効にし、[ ワイルドカード ] のチェックをオフのままにしておくことができます。 また、ドロップダウンメニューから [ Amazon Route 53 ] ホストゾーンを選択します。その後、ドメインの検証に必要な DNS CNAME レコードが ACM によって自動的に作成されるので、手動で行う必要はありません。ドメインが Route 53 の外部でホストされている場合、代わりに DNS プロバイダーで提供された CNAME レコードを手動で作成します。これは、各クライアントが独自のドメイン検証を個別に処理する一般的な ACME のセットアップとは大きく異なります。 これらの一元管理により、PKI 管理者は、ドメインの認証、クライアントがリクエストできる証明書の種類 (ECDSAまたはRSA) の制限、およびワイルドカードの発行の一元的な制限を行うことができます。これらのガバナンス機能が組み込まれているということは、証明書ライフサイクル管理製品を別途購入したり、カスタムポリシーレイヤーを自分で構築したりする必要がないということです。どちらも、多大なコストと運用上のオーバーヘッドを伴います。 [ ACME エンドポイントの作成 ] を選択します 数秒後、エンドポイントが作成されます。コンソールには、次のステップが記載された [ セットアップの進行状況 ] トラッカーが表示されます。ドメインには [検証中] ステータスが表示されます。検証方法は DNS 検証であり、ACM は特定の CNAME レコードをチェックしてお客様がドメインを管理していることを確認します。作成時に Route 53 ホストゾーンを選択したので、[ Route 53 にレコードを作成 ] を選択して ACM に DNS 検証を自動的に処理させます。 検証は数秒で完了し、ステータスが [ 成功 ] に変わります。 次に、外部アカウントバインディング (EAB) 認証情報を作成する必要があります。EAB 認証情報は、ACME クライアントが ACME サーバーにアカウントを登録できるようにするキー識別子と HMAC キーペアです。登録が完了すると、クライアントは独自の非対称キーペアを生成し、それを使用してその後のすべての証明書要求を認証します。エンドポイントの詳細ページで、[ 外部アカウントバインディング ] タブを選択し、[ EAB の作成 ] を選択します。認証情報に名前を付け、オプションで有効期限を設定します。理想的には、クライアント登録を完了するのに必要な時間を超えないようにします。 [ EAB 認証情報の作成 ] を選択すると、コンソールに [ キー ID ] と [HMAC キー] が表示されます。ACME クライアントの設定に必要なので、これらの値を書き留めておきます。セットアップの進行状況に 4 つの緑色のチェックマークが表示されました。 証明書をリクエストする準備ができました。エンドポイントの詳細ページで、[ CLI リファレンスセクション ] を展開します。コンソールには、 Certbot と acme.sh の両方ですぐに使えるコマンド例が用意されています。Certbot コマンドをコピーし、 certbot/certbot イメージを使用してコンテナ内で実行します。 certbot certonly --standalone --non-interactive --agree-tos \ --email <EMAIL> \ --server https://acm-acme-enroll.us-east-1.api.aws/<ENDPOINT_ID>/directory \ --eab-kid <EAB_KID> \ --eab-hmac-key <EAB_HMAC_KEY> \ --issuance-timeout <ISSUANCE_TIMEOUT> \ -d <DOMAIN> プレースホルダーをエンドポイント URL、EAB 認証情報、およびドメイン名に置き換えます。 --eab-kid および --eab-hmac-key 引数は、前に生成した外部アカウントバインディング認証情報を使用して Certbot が ACME エンドポイントに登録する方法です。各 ACME クライアントにはこのステップ用の独自の構文があるため、正確なフラグについてはクライアントのドキュメントを確認してください。 Certbot は ACME エンドポイントとコンタクトし、Amazon Trust Services によって署名された有効な証明書を返します。 証明書をインストールする前に、 openssl を使用して証明書を確認します。 これで、証明書が ACM コンソールの [ ACME 証明書 ] タブに、コンソールまたは API を通じて発行された証明書とともに表示されるようになりました。 利用可能性と料金 AWS Certificate Manager の ACME サポートは現在、すべての商用 AWS リージョンでご利用いただけます。後日、AWS GovCloud (米国)、中国リージョン、および AWS European Sovereign Cloud パーティション も利用できるようになります。 料金は発行時に各証明書に含まれるドメインごとで、完全修飾ドメイン名とワイルドカードでは料金が異なります。ボリューム階層は、お客様の AWS アカウントで毎月発行されるすべての証明書全体のドメイン出現数の合計に基づいて計算されます。詳細については、 ACM 料金ページ をご覧ください。 開始するには、 AWS コンソールの ACM セクション にアクセスするか、 ドキュメント をお読みください。 – seb 原文は こちら です。

今回は、OSS のクラウドセキュリティツール Prowler を使って AWS アカウントのセキュリティスキャンを試してみました。 「自分のアカウントのセキュリティ設定、大丈夫かな？」と気になったことがある方の参考になれば幸いです。 Prowler とは Prowler は AWS、Azure、GCP、Kubernetes に対応した OSS のセキュリティスキャンツールです。 CSPM（Cloud Security Posture Management）に分類されるツールで、CIS Benchmark や PCI-DSS、GDPR などのコンプライアンスフレームワークに基づいたチェックを実行…