×

現在、弊社サービスをご利用中ですか？

クラウドネイティブのCaaSプラットフォーム

高セキュリティのもとで、

圧倒的なユーザビリティで

マルチクラウドの開発・運用をサポート

  • スピーディーにデプロイ
  • コスト削減
  • 高可用性
  • 優れたスケーラビリティ

6.《Kubernetesと外部DNSサービス》

Banzai Cloudでは、私達はPipelineと呼ばれる、Kubernetes上のコンテナ用に構築された、機能豊富なエンタープライズアプリケーションプラットフォームを提供しています。エンタープライズレベルのアプリケーションプラットフォームの場合、セキュリティは必須であり、多くの構成要素があります。ブログのセキュリティシリーズをお読みいただき、私達がセキュリティ関連のさまざまな問題へどのように対処しているか御覧ください。

セキュリティシリーズ

OAuth2とVaultを使用してPipelineユーザーを認証および承認するKubernetesサービスアカウントを使用してVaultの動的認証情報を使用する

VaultとPipelineを使用した動的SSH

VaultとPipelineを使用してKubernetesデプロイメントを保護する

K8sおよびPipelineポリシーの実装

Vaultの「swiss-army knife」

10,000 Cloud Vaultオペレーター KMSでVaultを開く

この記事では、セキュリティの問題を解決するために外部DNSサービス、特にAmazonRoute53を使用する方法について説明します（AmazonRoute53のユーティリティはこの使用例に限定されません）。Pipelineを使用すると、ユーザーは主要なすべてのクラウドプロバイダー（AWS、GCP、Azure、Byocなど）のKubernetesクラスターにさまざまなアプリケーションをデプロイできます。

デプロイされたアプリケーションは、それが提供するサービスにアクセスできるパブリックエンドポイントを公開する場合があります。（たとえば、デプロイされたMySQLのホストとポート）。パブリックエンドポイントを保護するための1つの手順は、クライアントとサーバー間の通信チャネルのセキュリティを確保することです。これを実現するには、クライアントとサーバー間の接続をTLS（Transport Layer Security）プロトコルを使用して暗号化する必要があります。

サービスのTLSを設定するには、秘密鍵とサーバー証明書に公開鍵が含まれている必要があります。サーバー証明書は、自己署名証明書または有名な証明書プロバイダーからの商用証明書にすることができます。サーバー証明書の共通名は、サービスのURLと一致する必要があります。一致しない場合、クライアントは接続先のサービスを信頼しません。複数のURLからサービスにアクセスできる場合は、マルチドメインサーバー証明書が必要です。

クラウドでKubernetesを実行する場合、パブリックエンドポイントは通常、LoadBalancerタイプのサービスを通じて公開されます。Kubernetesは、クラウドプロバイダーのAPIを使用して、クラウドプロバイダーによって提供されるロードバランサーを作成します（たとえば、Amazonの場合は、Amazon Elastic Load Balancerになります）。クラウドプロバイダーによって作成されたロードバランサーにはいくらかコストがかかるため、ロードバランサーの数量を比較的低いレベルに維持することをお勧めします。これは、Pipelineでlngressを使用して実現できます。

入口に認証を追加する方法に興味がある場合は、入口の確認サイトを確認してください。

クラウドプロバイダーがロードバランサーを提供すると、パブリックIPと生成されたDNS名が割り当てられます。これは、タイプLoadBalancerのKubernetesサービスへのURLであり、次にアプリケーションを実行するKubernetesPodへのURLを指示します。これらは、Kubernetesで実行されているアプリケーションのパブリックエンドポイントがクラウド環境でどのように公開されるかのメカニズムです。

上記のように、このパブリックエンドポイントでTLSを設定するには、パブリック端末のURLと一致する共通名を使用してサーバー証明書を発行する必要があります。クラウドプロバイダーによって生成されたDNS名がわからないため、DNS名の準備ができてからサーバー証明書を提供し、TLSを使用するようにアプリケーションを構成できます。明らかに、これは持続可能ではなく、事前にTLSサーバー証明書を提供できるように、事前に定義されたURLでパブリックエンドポイントを公開できるソリューションが必要です。

Kubernetes ExternalDNSはソリューションを提供します。Kubernetesの外部のDNSプロバイダーにDNSレコードを設定して、外部のDNSプロバイダーを通じてKubernetesサービスを検出できるようにし、不明なDNSプロバイダーによる方法でDNSレコードを動的に制御できるようにします。

外部DNSがKubernetesクラスターにデプロイされたら、構成済みの外部DNSプロバイダーを介してKubernetesサービスを公開するのは、Kubernetesサービスに** 外部 DNS.alpha.kubernetes.io/hostname= **と注釈を付けるのと同じくらい簡単です。詳細については、外部DNSのインストール手順を参照してください。 これらのソリューションを使用すると、パブリックサービスにアクセスできるURLを制御できるため、TLSを使用するアプリケーションを展開する前に、TLSの適切なサーバー証明書を事前に作成できます。

Pipelineは何をもたらしたか？

Banzai Cloudの目標の1つは、可能な限り自動化してユーザーの生活を快適にすることです。 外部DNSの設定には多くの手順が必要ですが、Pipelineはユーザーのためにこれらの手順を処理します。

Pipelineを使用すると、サポートされている任意のクラウドプロバイダーで複数のKubernetesクラスターを作成できます。 エンドユーザーは1つ以上の組織に属しています。 クラスターを作成するとき、ユーザーはクラスターが属する組織を指定します。

その後Pipelineは以下を行います。

ROUTE 53ホスティングエリア
私達はDNSプロバイダーとしてAmazonRoute 53を使用します。Pipelineは、Route 53の次の形式で各組織のホスティングエリアを登録します：.。このドメインは、同じ組織に属するすべてのクラスターによって共有されます。

ROUTE 53アクセスポリシー

組織に属するKubernetesクラスターにデプロイされたさまざまなExternalDNSインスタンスは、その組織用に作成されたホストゾーンへのアクセスのみに制限する必要があります。これは、組織のホストゾーンのExternalDNSインスタンスの操作が別の組織のKubernetesクラスターにデプロイされないようにするために重要です。

AmazonのRoute 53アクセスポリシーは、特定のホストされたエリアへのアクセスを制限します。

{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: “route53:ChangeResourceRecordSets”,
“Resource”: “arn:aws:route53:::hostedzone/”
},
{
“Effect”: “Allow”,
“Action”: [
“route53:ListHostedZones”,
“route53:ListResourceRecordSets”
],
“Resource”: “*”
}
]
}

次に、IAMユーザーを作成し、Route53ポリシーをユーザーにアタッチします。 ExternalDNSは、IAMユーザーに代わってRoute 53の操作を実行します。これには、ユーザーのAWSアクセスキーを作成する必要があります。PipelineはBank-Vaultを使用してアクセスキーを作成し、安全な場所に保管します。

クラスターにExternalDNSをデプロイする

ExternalDNSがクラスターにデプロイされ、以前に作成されたIAMユーザーのAWSアクセスキーを使用するように構成されます。AWSアクセスキーはVaultから取得され、Kubernetes Secretsとしてクラスターに注入されます。 ExternalDNSは、このkubernetesを介してAWSアクセスキーにシークレットにアクセスできます。

未使用のROUTE 53ホスティングエリアを削除する

Pipelineは、kubernetesクラスターが実行されていない組織を検索することにより、未使用のroute53ホスティングエリアを定期的にチェックします。 これらの組織のホストされている領域は削除の候補です。さらに、PipelineはAmazonのRoute53定価モデルについて、以下のようなコスト低減も検討しました。

  1. 削除対象の未使用管理領域候補が過去12時間に作成されていないか確認する。 このような場合、ホスティングエリアを削除することができ、以下のRoute53規則に基づき価格は適用されません。「テストは行うことが出来ます、作成から12時間以内に削除されたホスティングエリアは課金されません…」
  2. もし未使用のホスティングエリアが12時間を超える場合は課金されます。そうした場合、ホスティングエリアを削除する理由はありません。削除後、同じ月の後半にエリアが再作成された場合、期間が12時間を超えると、再び課金されてしまいます。
  3. 現在の請求周期で請求された未使用のホスティングエリアは、次の請求サイクルが始まる前に削除します（前提としてこれらのエリアがまだ使用されていない場合）（「上記の月次管理エリア価格は、一ヶ月の中で比例配分されません。ホスティングエリアは、作成時および翌月の最初の日に課金されます」）。次の図は、上記のRoute 53フローを示しています。

TLS証明書

Pipelineは、自己署名TLS証明書の生成とVaultを使用した安全な場所への保存とKubernetesシークレットとしてのKubernetesクラスターへの注入をサポートしています。

ユーザーが行う必要があるのは、KubernetesSecretsのTLSキーを使用してTLSを有効にするようにアプリケーションのデプロイメントを構成することだけです。また、アプリケーションに注釈を付けることもできます。またexternaldns.alpha.kubernetes.io/ hostname = Kubernetesサービスを開いてRoute 53 DNSサービスに記録する事もできます。