2017-02-01 8 views
1

コンテナにデプロイされるサービスアカウントのca.crtファイルを調べました。マスターノードのDNS名。これにより、SSLエラーが発生します。https://0.0.0.0:10250/metrics:x509:IP SANが含まれていないため、0.0.0.0の証明書を検証できません。GKE ca.certに、APIサーバへの接続中にSSLエラーが発生するIPがありません。

誰かがこの問題に遭遇しましたか?あなたはどうやってそれを解決し、安全でないSSLを許しましたか?

答えて

2

サービスアカウント(/run/secrets/kubernetes.io/serviceaccount/ca.crt)によって提供されるca証明書は、(GKEのマスタがサービスする)apiserverと通信するためのものです。

# curl --cacert /run/secrets/kubernetes.io/serviceaccount/ca.crt https://kubernetes -H "Authorization: Bearer $(cat /run/secrets/kubernetes.io/serviceaccount/token)" 
{ 
    "paths": [ 
    "/api", 
    ... 
    ] 

kubelet API(ポート10250)と対話しているようです。 kubelet APIは自己署名証明書を提供するので、安全性が唯一の方法です。

+0

私はこの証明書の目的を理解していますが、自己署名証明書であっても、SANを追加して使用可能にすることは可能です。私の現在の問題は、自己署名されているかどうかにかかわらず、SANが足りなくなっていることです。私はapiサーバーを擦るプロメテウスインスタンスを実行しようとしましたが、 –

+0

私は完全に理解していないかもしれません。あなたがkubelet API(ポート10250)にヒットしようとしているようです。あなたがGKEマスターでkubeletを打つことを試みているなら、それは不可能です。あなたのノードでkubeletにヒットしようとしている場合、サービスアカウントのca証明書は役に立ちません。 –

+0

私はGKEノード上のkubelet APIにヒットしようとしています。それは、kubelet APIの証明書がAPI-Serverと同じCAを共有していないようです。使用されているCA証明書にアクセスしたり、GKEで自分のCA証明書を追加する方法はありますか?セキュアなSSLを使用してGKE上のkubelet APIにアクセスしたい場合はどうすればよいですか? –

関連する問題