2016-11-16 17 views
1

私はテストに入れたいGKE上で動作するKubernetes 1.4.5クラスタを持っています。テストでは、私は私のクラスタにアクセスできるソースIPアドレスを制限する一方でそれは送信元IPをIngressによって作成されたGCP Load Balancerに限定することはできますか

kind: Ingress 
apiVersion: extensions/v1beta1 
metadata: 
    name: keycloak-ingress 
    annotations: 
    kubernetes.io/ingress.allow-http: "false" 
    #kubernetes.io/ingress.class: "gce" 
spec: 
    tls: 
    - secretName: mysecret 
    backend: 
    serviceName: keycloak-https-service 
    servicePort: 443 

以下のようにイングレスを使用してHTTPSを受け入れます。ロードバランサはすべての着信トラフィックの送信元IPをローカルIPアドレスに変換するため、Google Cloudファイアウォールはこのトラフィックを制限できません。ロードバランサに入るトラフィックを制限する方法はありますか?

これは厳密にGCEに関する質問ですが、Kubernetesが提供する解決策があるかもしれません。

答えて

3

あなたはパイプラインを見ている:

GCE L7 LB - > VM:nodePort - >ポッド

トラフィックが行く:

GCE L7 LB - >あなたのvms

は、に記載されているように130.211.0.0/22から来るはずです。そのためには、すでにファイアウォールルールが設定されているはずです。行く 交通:

VMS - >コンテナ

は、あなたのVMのIPから来る必要があります。誰がノードに話しているのかを規制することはできません。ノードに誰が話しているのかを規制することができます。

不幸なことに、この状況のた​​めに、これはHTTP LBでは機能しません。あなたがパケットで実際のクライアントのソースIPを取得するので、L3/L4 LBで動作します。http://kubernetes.io/docs/user-guide/load-balancer/#annotation-to-modify-the-loadbalancer-behavior-for-preservation-of-source-ip

+0

ありがとうございます。私はL4に戻ってしまった(私は思う!)サービス –

+0

を利用していただきありがとうございます。 サービスタイプLoadBalancerを使用してL4に戻ってしまいましたが、私はまだソースIPを失っています。 GCPロードバランシングでは、フォワーディングルールのみがVMに供給されるターゲットプールに移動するようになりました。 GCPの方がいいですか? '種類:サービス apiVersion:v1の メタデータ: 名:keycloak-HTTPSサービス スペック: タイプ:ロードバランサ externalIPs: - xxx.xxx.xxx.xxx ポート: - ポート:443 targetPort :8443 名前:https セレクタ: app:keycloak-pod' –

+0

ターゲットコンテナに表示されるセッションのソースIPは、クライアントの元のソースIPではありません。これはKubernetes v1.5のデフォルト動作です。しかし、v1.5以降、オプションのベータ機能が追加され、GCE/GKE環境用のクライアントソースIPが保持されます。 – George

関連する問題