【问题标题】:GCP/GKE Add Network TagsGCP/GKE 添加网络标签
【发布时间】:2020-08-22 22:09:01
【问题描述】:

我正在尝试找到一种方法来改进我们的基础架构即 GCP 中的代码情况。我的希望是我可以

  1. 根据添加的目标标签创建防火墙规则白名单
  2. 将目标标签作为部署 yaml 配置的一部分。

我希望通过在部署中添加标签,我可以让它自动将这些标签应用于它创建的任何计算资源或负载均衡器。这样,可以通过 terraform 创建适用于这些标签的防火墙规则。

我是不是走错了路,还是有办法做到这一点?这既关乎自动化防火墙规则管理,也关乎清理可能干扰操作的不必要规则。

【问题讨论】:

  • 你能举一个这样的规则的例子吗?在这种情况下,我们是否只谈论GKE? GKE 集群是一个托管解决方案,它会自动为您做很多事情,比如防火墙规则和负载均衡器配置。
  • 它会自动执行防火墙规则,但我不能告诉您自定义它们。如果我想让它成为一个只允许特定 CIDR 范围的白名单规则,我不知道有任何方法可以做到这一点。我想阻止第 3 层到入口或负载均衡器的流量,只允许我们的办公室或 VPN 范围访问。

标签: yaml terraform google-kubernetes-engine kubectl infrastructure-as-code


【解决方案1】:

GCP 正在积极使用network tags 来标记受防火墙规则(允许、阻止)影响的资源。这些标签与 Compute Engine 实例、托管组等相关联。

Kubernetes 使用labels 来标记服务使用的资源(暴露您的应用程序)。

network tags 和labels 以上是独立的资源,不能在GCP/GKE 环境中一起使用。

请查看有关这些资源的官方文档:


当您在GKE 中创建LoadBalancer 类型的服务时,您会自动为其创建转发规则。以后可以修改/编辑此规则。可以将其编辑为仅允许来自某些 IP 地址(如家庭/办公室等)的请求的状态。

可以用GCP Dashboard -> VPC Network -> Firewall手动修改。

我发现了一个使用 Terraform 的解决方法,它允许修改由 GKE 创建的现有转发规则。


考虑到上述情况,我使用 Terraform 和 GKE 为 LoadBalancer 创建了一个示例。步骤:

  • 产生工作负载。
  • 将工作负载暴露给外部使用。
  • 编辑现有转发规则以阻止来自某些 CIDR/s 的流量。

假设:

  • Terraform 已安装并可访问 GCP
  • GKE 集群已配置
  • kubectl 设置为连接到上面的集群

以上步骤参考:Learn.hashicorp.com: Terraform: Provision GKE cluster

至于Ingress。管理它在很大程度上取决于使用的解决方案,例如:

  • ingress-nginx
  • ingress-gce

产生工作负载

下面的例子 nginx deployment 将用于响应请求:

resource "kubernetes_deployment" "nginx" {
  metadata {
    name = "scalable-nginx-example"
    labels = {
      App = "ScalableNginxExample"
    }
  }

  spec {
    replicas = 2
    selector {
      match_labels = {
        App = "ScalableNginxExample"
      }
    }
    template {
      metadata {
        labels = {
          App = "ScalableNginxExample"
        }
      }
      spec {
        container {
          image = "nginx:1.7.8"
          name  = "example"

          port {
            container_port = 80
          }

          resources {
            limits {
              cpu    = "0.5"
              memory = "512Mi"
            }
            requests {
              cpu    = "50m"
              memory = "50Mi"
            }
          }
        }
      }
    }
  }
}

将工作负载暴露给外部使用

下面的定义将为 nginx 部署创建LoadBalancer 类型的服务:

resource "kubernetes_service" "nginx" {
  metadata {
    name = "nginx-example"
  }
  spec {
    selector = {
      App = kubernetes_deployment.nginx.spec.0.template.0.metadata[0].labels.App
    }
    port {
      port        = 80
      target_port = 80
    }

    type = "LoadBalancer"
  }
}

output "lb_ip" {

value = kubernetes_service.nginx.load_balancer_ingress[0].ip

}

GKE 将自动创建转发规则并为负载均衡器分配 IP 地址。 Terraform 不会识别此转发规则,需要导入此转发规则才能对其进行修改。

请具体查看lb_ip 部分。 Terraform成功运行后,这部分会输出一个LoadBalancer的IP。此值可用于标识与服务关联的转发规则。

编辑现有转发规则以阻止来自某些 CIDR/s 的流量

如上所述:

Terraform 不会识别此转发规则,需要导入此转发规则才能对其进行修改。

这里的问题是需要一些自编写脚本才能完全自动化此解决方法。

转发规则名称是修改它所必需的。

从GCP基础设施中提取转发规则名称的方法之一是:

  • 从以下地址获取LoadBalancer IP:
    • $ kubectl get svc nginx-example
  • 从以下位置获取 forwarding rule 名称:
    • $ gcloud compute firewall-rules list --format=json

免责声明: 上面的命令将以 json 格式输出所有防火墙规则,包括目标标签、优先级和描述等详细信息。 LoadBalancer IP 将位于防火墙规则的说明部分中。

  • 提取的转发规则名称应类似于:
    • k8s-fw-aefb2110aad9e11ea971d42010a9c00a
  • 使用上述名称在Terraform中创建资源:

    • 在文件中创建所需的forwarding rule 定义。请查看下面的示例规则并根据您的用例进行更改。该资源可以用作另一个新资源的模板。请确保target_tags 与未修改版本相同。

      转发规则的示例定义:

resource "google_compute_firewall" "YOUR-NAME-OF-FORWARDING" {
  project = "PROJECT-NAME"
  provider = google-beta
  name = "k8s-fw-aefb2110aad9e11ea971d42010a9c00a"
  network = "PROJECT-NETWORK"
  source_ranges = ["1.2.3.4/32"]
  priority = "1000"
  allow {
    protocol = "tcp"
    ports = ["80"]
    }
  target_tags = ["gke-PROJECT-NAME-gke-c6d3956c-node"] # 
  direction = "INGRESS"
  }
  • 导入资源:
$ terraform import google_compute_firewall.YOUR-NAME-OF-FORWARDING projects/PROJECT-NAME/global/firewalls/k8s-fw-aefb2110aad9e11ea971d42010a9c00a`

发出$ terraform apply 时,您应该能够在forwarding rule 中看到所需的更改,如下所示(部分):

 ~ source_ranges           = [
     - "0.0.0.0/0",
     + "1.2.3.4/32",
   ]

应用您的防火墙规则转发流量后,应进行修改!

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2023-03-03
    • 1970-01-01
    • 2020-02-02
    • 1970-01-01
    • 2022-11-17
    • 2022-06-14
    • 2020-11-01
    • 2020-12-09
    相关资源
    最近更新 更多