この記事はKubernetesにおける証明書の動作メカニズムを徹底的に理解するのに役立ちます

この記事はKubernetesにおける証明書の動作メカニズムを徹底的に理解するのに役立ちます

この記事はWeChatの公開アカウント「趙華兵」から転載したものです。この記事を転載する場合は、趙華兵の公開アカウントにご連絡ください。

[[328701]]

目次

  • Kubernetes コンポーネント認証
  • Kubernetes で使用される CA と証明書
  • Kubernetes での証明書の設定
    • etcd 証明書の設定
    • kube-apiserver 証明書の設定
    • kubeconfig を使用して kube-apiserver にアクセスする
    • サービスアカウント証明書
    • Kubernetes 証明書の発行
    • TLS ブートストラップを使用して Kubelet 証明書の作成を簡素化する
  • まとめ
  • 参照ドキュメント

Kubernetes コンポーネント認証

まず、Kubernetes のコンポーネントを見てみましょう。Kubernetes には、独立したプロセスとして実行される複数のコンポーネントが含まれています。これらのコンポーネントは、HTTP/GRPC を介して相互に通信し、クラスター内のアプリケーションの展開と管理を共同で完了します。

Kubernetes コンポーネント、画像ソース: kubernetes.io

図からわかるように、Kubernetes コントロール プレーンには、etcd、kube-api-server、kube-scheduler、kube-controller-manager などのコンポーネントが含まれています。これらのコンポーネントは相互にリモート呼び出しを行います。たとえば、kube-api-server は etcd インターフェースを呼び出してデータを保存し、kube-controller-manager は kube-api-server インターフェースを呼び出してクラスター内のオブジェクトのステータスを照会します。同時に、kube-api-server は動作ノード上の kubelet および kube-proxy とも通信し、動作ノード上でアプリケーションをデプロイおよび管理します。

上記コンポーネント間の相互呼び出しはすべてネットワークを介して実行されます。ネットワーク経由で通信する場合、悪意のある第三者が ID を偽造して情報を盗んだりシステムを攻撃したりするのを防ぐために、両者は互いの ID を確認する必要があります。お互いの身元を確認するには、通信の当事者のどちらかが次の 2 つのことを行う必要があります。

  • 相手に身元を証明する証明書を提供する
  • 相手側から提供された身分証明書が合法か偽造かを確認しますか?

Kubernetes では、ID 証明を提供するためにデジタル証明書が使用されます。デジタル証明書は、日常生活で使用する「身分証明書」と簡単に理解できます。これには、名前、組織などの証明書所有者の身元情報が含まれています。証明書の権限を保証するために、通信する両方の当事者が信頼する CA (証明機関) を使用して証明書が発行されます。これは現実世界で「身分証明書」を発行する政府機関に似ています。デジタル証明書で最も重要なコンテンツは、実際には証明書所有者の公開キーであり、ユーザーの ID を表します。この記事では、読者がデジタル証明書と CA の基本原則をすでに理解していることを前提としています。これについてよくわからない場合、または関連する知識を確認したい場合は、まずこの記事「デジタル証明書の原則」（https://zhaohuabing.com/post/2020-03-19-pki）をお読みください。

CA (証明機関)、画像ソース www.trustauth.cn

Kubernetes コンポーネントが相互に通信する場合、TLS を介してプロトコル レベルでデジタル証明書の検証が行われます。通信を確立するときに関連する証明書とキーを提供する以外に、アプリケーション レベルで特別な処理は必要ありません。認証に TLS を使用する方法は 2 つあります。

  • サーバー一方向認証: 証明書を提供する必要があるのはサーバーのみです。クライアントはサーバー証明書を通じてサービスの ID を検証しますが、サーバーはクライアントの ID を検証しません。この状況は、検索エンジンの Web サイトなど、インターネットに公開されているサービスに一般的に当てはまります。どのクライアントもサーバーに接続してアクセスできますが、偽の悪意のあるサーバーに接続するのを避けるために、クライアントはサーバーの ID を確認する必要があります。
  • 双方向 TLS 認証: クライアントがサーバーの証明書を検証する必要があるだけでなく、サーバーもクライアント証明書を通じてクライアントの ID を検証する必要があります。この場合、サーバーは機密情報を提供し、特定の ID を持つクライアントのみがその情報にアクセスできるようになります。

Kubernetes では、さまざまなコンポーネントによって提供されるインターフェースに、クラスターの内部情報が含まれています。これらのインターフェースに不正にアクセスされると、クラスターのセキュリティに影響が出るため、コンポーネント間の通信には相互 TLS 認証が必要です。つまり、クライアントとサーバーの両方が互いの ID 情報を検証する必要があります。 2 つのコンポーネントが双方向認証を実行する場合、次の証明書関連ファイルが関係します。

  • サーバー証明書: サーバーが自身の ID を証明するために使用するデジタル証明書。主にサーバーの公開キーとサーバーの ID 情報が含まれます。
  • サーバー秘密キー: サーバー証明書に含まれる公開キーに対応する秘密キー。公開鍵と秘密鍵はペアで使用されます。 TLS 検証中、サーバーは秘密キーを使用して、サーバー証明書の所有者であることをクライアントに証明します。
  • クライアント証明書: クライアントが自身の ID を証明するために使用するデジタル証明書。主にクライアントの公開キーとクライアントの ID 情報が含まれます。
  • クライアント秘密キー: クライアント証明書に含まれる公開キーに対応する秘密キー。同様に、クライアントはこの秘密鍵を使用して、クライアント証明書の所有者であることをサーバーに証明します。
  • サーバー側 CA ルート証明書: サーバー側証明書を発行する CA ルート証明書。クライアントはこの CA ルート証明書を使用して、サーバー側証明書の正当性を検証します。
  • クライアント CA ルート証明書: クライアント証明書を発行する CA ルート証明書。サーバーはこの CA ルート証明書を使用して、クライアント証明書の正当性を検証します。

「TLS、X509、相互認証の魔法の説明」という記事からの次の図は、相互 TLS 認証の原理をわかりやすく説明しています。 TLS 認証の原理について詳しく知りたい場合は、Medium のオリジナル記事 (https://medium.com/sitewards/the-magic-of-tls-x509-and-mutual-authentication-explained-b2162dec4401) をお読みください。

画像ソース: TLS、X509、相互認証の魔法を解説

Kubernetes で使用される CA と証明書

Kubernetes では多くの証明書が使用されています。この記事では、考えられるすべての証明書を網羅するのではなく、主な証明書について説明します。これらの証明書の使用方法と動作理由を理解すれば、今後遭遇する可能性のある他の証明書ファイルについてもすぐに理解できるようになります。次の図は、Kubernetes で使用される主な証明書とその使用場所を示しています。

Kubernetesで使用される主な証明書

証明書には、上の画像のようにシリアル番号が付けられています。図中の矢印はコンポーネントの呼び出し方向を示しています。矢印の方向はサービス プロバイダーであり、もう一方の端はサービス呼び出し元です。 TLS 双方向認証を実装するには、サービス プロバイダーがサーバー証明書を使用し、サービス呼び出し元がクライアント証明書を提供し、両方の当事者が CA 証明書を使用して相手側が提供した証明書を検証する必要があります。簡潔にするために、上の図では、証明書ユーザーによって提供された証明書のみをマークし、証明書検証者によって使用される CA 証明書はマークしていません。図にマークされている証明書の機能は次のとおりです。

  1. etcd クラスター内のノードが相互に通信するために使用する証明書。 etcd ノードは他のノードにサービスを提供するだけでなく、クライアントとして他のノードにアクセスする必要があるため、証明書はサーバー証明書とクライアント証明書の両方として使用されます。
  2. etcd クラスターは証明書を使用して外部サービスを提供します。この証明書はサーバー証明書です。
  3. kube-apiserver がクライアントとして etcd にアクセスするために使用する証明書。この証明書はクライアント証明書です。
  4. kube-apiserver が外部サービスを提供するために使用する証明書。この証明書はサーバー証明書です。
  5. kube-controller-manager がクライアントとして kube-apiserver にアクセスするために使用する証明書は、クライアント証明書です。
  6. kube-scheduler がクライアントとして kube-apiserver にアクセスするために使用する証明書は、クライアント証明書です。
  7. kube-proxy がクライアントとして kube-apiserver にアクセスするために使用する証明書は、クライアント証明書です。
  8. kubelet がクライアントとして kube-apiserver にアクセスするために使用する証明書は、クライアント証明書です。
  9. 管理者ユーザーが kubectl を介して kube-apiserver にアクセスするために使用する証明書は、クライアント証明書です。
  10. kubelet が外部サービスを提供するために使用する証明書。この証明書はサーバー証明書です。
  11. kubelet にアクセスするためのクライアントとして kube-apiserver が使用する証明書。この証明書はクライアント証明書です。
  12. kube-controller-manager は、サービス アカウント トークンの証明書を生成および検証するために使用されます。この証明書は、他の証明書のように ID 認証には使用されません。代わりに、証明書内の公開キーと秘密キーのペアを使用して、サービス アカウント トークンを生成および検証します。 kube-controller-manager は証明書の秘密鍵を使用してサービス アカウント トークンを生成し、それをシークレットとしてポッドにロードします。ポッド内のアプリケーションはトークンを使用して kube-apiserver にアクセスでき、kube-apiserver は証明書内の公開キーを使用してリクエスト内のトークンを検証します。この証明書の使用方法については、この記事の後半で詳しく説明します。

この図から、証明書のメカニズムに詳しい読者は、実際に複数の異なる CA を使用してこれらの証明書を発行できることがわかったかもしれません。相手側の証明書を検証するために使用される CA ルート証明書が通信コンポーネントで正しく構成されている限り、異なる CA を使用して異なる目的で証明書を発行できます。ただし、一般的には、Kubernetes クラスター内のすべての証明書を発行するには、統合 CA を使用することをお勧めします。これは、複数の CA を使用するよりも、クラスター ルート CA を使用する方が管理が容易だからです。複数の CA によって発生する複雑な証明書の構成と更新を回避し、誤った証明書の構成によって発生するクラスター障害を軽減できます。

Kubernetes での証明書の設定

先ほど、Kubernetes クラスターで使用される主な証明書を紹介しました。次に、これらの証明書とそれに対応する秘密鍵および CA ルート証明書を Kubernetes のさまざまなコンポーネントに構成して、各コンポーネントで使用する方法について説明します。ここでは、関連するすべての証明書を発行するためにクラスター ルート CA が使用されることを前提としています。したがって、CA 構成に対応する証明書ファイル名は同じになります。

etcd 証明書の設定

etcd 起動コマンドラインで次の証明書関連のパラメータを設定する必要があります。

  • 外部サービスを提供するためのetcdサーバー証明書と秘密鍵。
  • etcd ノードが相互に認証するために使用するピア証明書と秘密鍵、およびピアを検証する CA。
  • etcd は、サービスにアクセスするクライアントの CA を検証します。
  1.  /usr/ローカル/bin/etcd \\
  2.  --cert-file=/etc/etcd/kube-etcd.pem \\ # 外部サービスを提供するためのサーバー証明書 
  3.  --key-file=/etc/etcd/kube-etcd-key.pem \\ # サーバー証明書に対応する秘密鍵 
  4.  --peer-cert-file=/etc/etcd/kube-etcd-peer.pem \\ # etcdノード間の相互アクセスに使用されるピア証明書 
  5.  --peer-key-file=/etc/etcd/kube-etcd-peer-key.pem \\ # ピア証明書に対応する秘密鍵 
  6.  --trusted-ca-file=/etc/etcd/cluster-root-ca.pem \\ # etcd サーバーにアクセスするクライアント証明書の検証に使用される CA ルート証明書 
  7.  --peer-trusted-ca-file=/etc/etcd/cluster-root-ca.pem\\ # ピア証明書の検証に使用される CA ルート証明書 
  8.   ...

kube-apiserver 証明書の設定

kube-apiserver で次の証明書関連のパラメータを設定する必要があります。

  • kube-apiserver が外部サービスを提供するために使用するサーバー証明書と秘密キー。
  • kube-apiserver が etcd にアクセスするために必要なクライアント証明書と秘密キー。
  • kube-apiserver が kubelet にアクセスするために必要なクライアント証明書と秘密キー。
  • サービスにアクセスするクライアントを認証する CA。
  • etcd サーバー証明書の CA ルート証明書を確認します。
  • サービス アカウント トークンの検証に使用される公開キー。
  1.  /usr/ローカル/bin/kube-apiserver \\
  2.  --tls-cert-file=/var/lib/kubernetes/kube-apiserver.pem \\ # 外部サービスを提供するために使用されるサーバー証明書 
  3.  --tls-private-key-file=/var/lib/kubernetes/kube-apiserver-key.pem \\ # サーバー証明書に対応する秘密鍵 
  4.  --etcd-certfile=/var/lib/kubernetes/kube-apiserver-etcd-client.pem \\ # etcd にアクセスするためのクライアント証明書 
  5.  --etcd-keyfile=/var/lib/kubernetes/kube-apiserver-etcd-client-key.pem \\ # etcd へのアクセスに使用するクライアント証明書の秘密鍵 
  6.  --kubelet-client-certificate=/var/lib/kubernetes/kube-apiserver-kubelet-client.pem \\ # kubelet にアクセスするためのクライアント証明書 
  7.  --kubelet-client-key=/var/lib/kubernetes/kube-apiserver-kubelet-client-key.pem \\ # kubelet にアクセスするためのクライアント証明書の秘密鍵 
  8.  --client-ca-file=/var/lib/kubernetes/cluster-root-ca.pem \\ # kube-apiserver にアクセスするクライアント証明書の検証に使用される CA ルート証明書 
  9.  --etcd-cafile=/var/lib/kubernetes/cluster-root-ca.pem \\ # etcd サーバー証明書の検証に使用される CA ルート証明書 
  10.  --kubelet-certificate-authority=/var/lib/kubernetes/cluster-root-ca.pem \\ # kubelet サーバー証明書の検証に使用される CA ルート証明書 
  11.  --service-account-key-file=/var/lib/kubernetes/service-account.pem \\ # サービス アカウント トークンの検証に使用する公開鍵 
  12.   ...

kubeconfig を使用して kube-apiserver にアクセスする

kube-controller-mananger、kube-scheduler、kube-proxy、kubelet など、Kubernetes の各コンポーネントは、kubeconfig ファイルで構成された情報を使用して kube-apiserver にアクセスします。このファイルには、kube-apiserver のアドレス、kube-apiserver サーバー証明書を検証するための CA 証明書、独自のクライアント証明書と秘密鍵、およびその他のアクセス情報が含まれています。

minikube がインストールされたクラスターでは、生成される kubeconfig 構成ファイルは次のようになります。これら 4 つのファイルは、管理者ユーザー、kube-controller-mananger、kubelet、および kube-scheduler の kubeconfig 構成ファイルです。

  1.  $ ls /etc/kubernetes/
  2.  admin.conf コントローラマネージャ.conf kubelet.conf スケジューラ.conf

controller-manager.conf を開いて確認してみましょう。

  1.  APIバージョン: v1
  2. クラスター:
  3.  - クラスター:
  4.     # kube-apiserver サーバー証明書の検証に使用される CA ルート証明書
  5.  
  6.     証明書機関データ: ==
  7.     サーバー: https://localhost:8443
  8. 名前: Kubernetes
  9. コンテキスト:
  10.  - コンテクスト：
  11.     クラスター: Kubernetes
  12. ユーザー: system:kube-controller-manager
  13. 名前: system:kube-controller-manager@kubernetes
  14. 現在のコンテキスト: system:kube-controller-manager@kubernetes
  15. 種類: 設定
  16. 設定: {}
  17. ユーザー:
  18.  -名前: system:kube-controller-manager
  19. ユーザー:
  20.     # kube-apiserver にアクセスするためのクライアント証明書
  21.  
  22.     クライアント証明書データ: ==
  23.     # クライアント証明書に対応する秘密鍵
  24.  
  25.     クライアントキーデータ: ==

ご覧のとおり、kube-apiserver にアクセスするために必要な関連証明書の内容が、base64 エンコーディングを使用してファイルに書き込まれています。他のファイルの内容は、構成されたユーザー名とクライアント証明書が異なることを除いて同様です。

これらのコンポーネントを起動するときは、パラメータに kubeconfig ファイルのパスを指定する必要があります。例えば、kube-controller-manager の起動コマンドは以下のようになります。

  1.  /usr/ローカル/bin/kube-controller-manager \\
  2.  --kubeconfig=/etc/kubernetes/コントローラマネージャ.conf  
  3.  # 次の証明書は、kube-apiserver へのアクセスとは関係ありません。後ほど紹介させていただきます。
  4.  --cluster-signing-cert-file=/var/lib/kubernetes/cluster-root-ca.pem # 証明書を発行するために使用される CA ルート証明書 
  5.  --cluster-signing-key-file=/var/lib/kubernetes/cluster-root-ca-key.pem # 証明書の発行に使用される CA ルート証明書の秘密鍵 
  6.  --service-account-private-key-file=/var/lib/kubernetes/service-account-key.pem # サービス アカウント トークンの署名に使用される秘密鍵 
  7.  ...

サービスアカウント証明書

Kubernetes には、ユーザー アカウントとサービス アカウントの 2 種類のユーザーが存在します。サービス アカウントは主に、ポッドが kube-apiserver にアクセスするために使用されます。ポッドのサービス アカウントを指定すると、Kubernetes はサービス アカウントの JWT トークンを生成し、シークレットを使用してサービス アカウント トークンをポッドにロードします。ポッド内のアプリケーションは、サービス アカウント トークンを使用して API サーバーにアクセスできます。サービス アカウント証明書は、サービス アカウント トークンの生成と検証に使用されます。この証明書の使用方法は、公開鍵と秘密鍵が実際に使用され、証明書を検証する必要がないため、上で紹介した他の証明書とは異なります。

次に示すように、サービス アカウント証明書の公開キーと秘密キーは、それぞれ kube-apiserver と kube-controller-manager のコマンド ライン パラメーターで構成されていることがわかります。

  1.  /usr/ローカル/bin/kube-apiserver \\
  2.  --service-account-key-file=/var/lib/kubernetes/service-account.pem \\ # サービス アカウント トークンの検証に使用する公開鍵 
  3.   ... 
  4.    
  5.  /usr/ローカル/bin/kube-controller-manager \\
  6.  --service-account-private-key-file=/var/lib/kubernetes/service-account-key.pem # サービス アカウント トークンの署名に使用される秘密鍵 
  7.  ...

次の図は、Kubernetes でサービス アカウント トークンを生成、使用、検証するプロセスを示しています。

認証方法: クライアント証明書またはトークン?

前回の紹介から、Kubernetes は 2 つのクライアント認証方法を提供していることがわかります。コントロール プレーン コンポーネントはクライアントのデジタル証明書を使用します。クラスターにデプロイされたアプリケーションはサービス アカウント トークンを使用します。 Kubernetes がサービス アカウントの証明書を生成して ID 認証に使用しないのはなぜですか?実際、これが Istio が行うことです。 Istio は各サービス アカウントの証明書を自動的に生成し、その証明書を使用してポッド内のアプリケーション間の双方向 TLS 認証を確立します。 Kubernetes でのこの設計上の決定についての説明は見つかりませんでしたが、理由をご存知でしたら教えてください。

Kubernetes 証明書の発行

Kubernetes は、構成された CA ルート証明書を使用してユーザー証明書を発行できる certificates.k8s.io API を提供します。この API は kube-controller-manager によって実装されており、証明書の発行に使用されるルート証明書は次のコマンドラインで構成されます。 Kubernetes がクラスター ルート CA を使用してユーザー証明書を発行することを期待しているため、kube-controller-manager のコマンド ライン パラメーターでクラスター ルート CA に関連するパラメーターを構成します。

  1.  /usr/ローカル/bin/kube-controller-manager \\
  2.  --cluster-signing-cert-file=/var/lib/kubernetes/cluster-root-ca.pem # 証明書を発行するために使用される CA ルート証明書 
  3.  --cluster-signing-key-file=/var/lib/kubernetes/cluster-root-ca-key.pem # 証明書の発行に使用される CA ルート証明書の秘密鍵 
  4.  ...

Kubernetes 証明書署名 API の詳細については、「クラスターでの TLS 認証の管理」を参照してください。

TLS ブートストラップを使用して Kubelet 証明書の作成を簡素化する

Kubernetes をインストールするときは、各ワーカー ノードで Kubelet の証明書を生成する必要があります。動作中のノードが多数ある場合があるため、Kubelet 証明書を手動で生成するプロセスは面倒です。この問題を解決するために、Kubernetes は TLS ブートストラップ (https://kubernetes.io/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) を提供し、Kubelet 証明書生成プロセスを簡素化します。原則としては、事前にブートストラップ トークンを提供し、それを介して kubelet が kube-apiserver の証明書発行 API を呼び出して必要な証明書を生成することです。この機能を有効にするには、kube-apiserver で --enable-bootstrap-token-auth を有効にし、kubelet が kube-apiserver にアクセスするために使用するブートストラップ トークン シークレットを作成する必要があります。 kubeadmin を使用してインストールする場合は、kubeadm token create コマンドを使用してトークンを作成できます。

TLS ブートストラップを使用して証明書を生成するプロセスは次のとおりです。

  1. kube-apiserver を呼び出してブートストラップ トークンを生成します。
  2. kubelet が kube-apiserver を呼び出すためのクライアント認証方法として、ブートストラップ トークンを kubeconfig ファイルに書き込みます。
  3. ブートストラップ トークンは、--bootstrap-kubeconfig 起動パラメータを介して kubelet プロセスに渡されます。
  4. Kubelet はブートストラップ トークンを使用して kube-apiserver API を呼び出し、必要なサーバー証明書とクライアント証明書を生成します。
  5. 証明書が生成されると、Kubelet は生成された証明書を使用して kube-apiserver と通信し、ブートストラップ トークンの漏洩のリスクを回避するためにローカルの kubeconfig ファイルを削除します。

まとめ

Kubernetes は、クラスターのセキュリティを確保するために多数の証明書を使用します。これらの証明書の目的と構成を理解することで、Kubernetes のインストール プロセスとコンポーネント構成をより深く理解できるようになります。この記事は、私が学習する過程でまとめた、Kubernetes クラスターで使用される主な証明書の概要です。 Kubernetes に関する私の理解が限られているため、この記事にはいくつかの誤りが避けられません。訂正していただいても結構です。

参照ドキュメント

Kubernetes PKI 証明書と要件 (https://kubernetes.io/en/docs/setup/best-practices/certificates/)

Kubernetes の難しい方法 (https://github.com/kelseyhightower/kubernetes-the-hard-wa)

Kubernetes バイナリのインストール (パート 2) 証明書の詳細 (https://blog..com/13210651/2361208)

TLS ブートストラップ (https://kubernetes.io/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)

デジタル証明書の原則 (https://zhaohuabing.com/post/2020-03-19-pki/)

<<:  クラウドネイティブへの道: コンテナ技術の実装

>>:  クラウドとSaaSのセキュリティには包括的なアプローチが必要

推薦する

KVM を補充、123systems - $7/年/KVM/256m メモリ/10g SSD/500g トラフィック

123systems は colorcrossing に正式に買収されて以来、何の動きもなかったよう...

張建鋒：アリババの自社開発チップは来年発売予定

[51CTO.comよりオリジナル記事] アリババは昨年10月にDAMOアカデミーを正式に設立した。...

権限委譲における 5 つの大きな間違い - 外部リンク

毎日絶えずアウトバウンド リンクを送信している友人は、この記事を注意深く読んでください。この記事では...

v5net: 335元/月、香港独立サーバー、香港Alibaba CN2専用回線、e5-2630L/4gメモリ/240gSSD/5M帯域幅

V5 SERVERは香港と日本のT3レベルのハイエンドコンピュータルームで独立サーバーを主に運営して...

Function as a Service (FaaS) とは何ですか?

Function as a Service (FaaS) は、開発者が独自のインフラストラクチャを維...

TIC2018: 需要と供給のギャップを埋めるには、需要を満たすクラウドサービスが唯一の道

クラウドによる変革は、ほとんどの企業にとって IT 展開をアップグレードするための選択肢となっていま...

今日最もホットでターゲットを絞ったマーケティング: 検索エンジンマーケティング SEM/SEO

ネットユーザーがインターネットに参入する主要な入り口として、検索エンジンが企業のプロモーションにとっ...

マイクロソフト、金融・製造業向け3つの業界クラウド製品をリリース

マイクロソフトは25日、特定業種向けの3​​つの新しいクラウド製品「Microsoft Cloud ...

済南小児病院：XEOS は分散オブジェクト アクティブ アクティブ ストレージを構築し、容量とパフォーマンスの両方を実現

各レベルの医療機関における事業の継続的な発展に伴い、さまざまな健康診断のために多数の画像診断装置が病...

IoT、5G、エッジコンピューティングの発展が業界のイノベーションを推進している

現在、消費者部門の接続された IoT デバイスの数は産業部門のそれを上回っていますが、業界固有のニー...

エッジコンピューティング: 次世代のイノベーション

エンタープライズ テクノロジーの将来は、データ センターやパブリック クラウドに限定されません。エッ...

SKYCC統合マーケティングソフトウェア：通常のマーケティングソフトウェアよりも使いやすい

電子商取引は急速に発展しており、オンラインマーケティングもそれに応じて変化しています。新興の人気産業...

ダブルイレブンのウール獲得戦略がここに

いよいよ待ちに待った11.11がやって来ます。数日前まではまだダブルイレブンの売上の上がり下がりを予...

大きなエネルギーが待ち受けている：中国電子クラウドがクラウドコンピューティング市場に参入、警笛が鳴る

2020年9月9日、「信頼できるクラウド、未来を創る」をテーマにした中国電子クラウド戦略会議が武漢で...

A5マーケティング：現段階での企業ウェブサイトの外部リンク構築の2つの異なる方法の簡単な分析

最近、筆者は他業種のウェブマスターとコミュニケーションを取っています。コミュニケーションの過程で、企...