目次
こんにちは松原です。
2022/4/1にCloud Armor がTCP Proxy load balancers と SSL proxy load balancers でパブリックプレビューとしてサポートされました。 弊社のプロジェクトではTCP LB を使用しているプロジェクトもあるので、どのように動くのか試していきたいと思います。
構築
構築はTerraformにて行っていきます。
GCE
適当に小さなスペックのNginxサーバーを立てます。
data "google_compute_image" "centos7" {
family = "centos-7"
project = "centos-cloud"
}
resource "google_compute_instance" "default" {
name = "tcp-instance"
machine_type = "e2-small"
zone = "asia-northeast1-b"
tags = ["tcp-instance"]
boot_disk {
device_name = "tcp-instance"
initialize_params {
image = data.google_compute_image.centos7.self_link
size = 20
type = "pd-standard"
}
}
network_interface {
network = "default"
access_config {
}
}
service_account {
scopes = ["cloud-platform"]
}
metadata = {
"startup-script" = <<-EOT
yum install -y nginx
systemctl start nginx
EOT
}
}
Firewall
GCP LB からのヘルスチェックのIP130.211.0.0/22 35.191.0.0/16 のアクセス許可を行います。
variable "ip-gcp-lb" {
type = list(string)
default = [
"130.211.0.0/22",
"35.191.0.0/16",
]
}
resource "google_compute_firewall" "default" {
name = "tcp-instance-allow"
network = "default"
allow {
protocol = "tcp"
ports = []
}
source_ranges = var.ip-gcp-lb
target_tags = [
"tcp-instance"
]
}
Instance Group
作成したGCEインスタンスを含むインスタンスグループを作成します。
resource "google_compute_instance_group" "default" {
name = "tcp-instance-group"
instances = [
google_compute_instance.default.self_link,
]
named_port {
name = "http"
port = "80"
}
zone = "asia-northeast1-b"
}
Backend Service
作成したインスタンスグループを含むバックエンドサービスを作成していきます。
それと同時にヘルスチェック・Cloud Armor も作成します。
バックエンドサービスはprotocol指定をTCPにします。
port も適当に8099で受けるようにします。
resource "google_compute_health_check" "default" {
name = "tcp-health-check"
timeout_sec = 1
check_interval_sec = 1
tcp_health_check {
port = "80"
}
}
resource "google_compute_security_policy" "default" {
name = "tcp-armor"
rule {
action = "allow"
description = "デフォルトのルール。優先度が高いとオーバーライドされます"
priority = 2147483647
preview = false
match {
versioned_expr = "SRC_IPS_V1"
config {
src_ip_ranges = [
"*",
]
}
}
}
}
resource "google_compute_backend_service" "default" {
name = "tcp-lb"
port_name = "http"
protocol = "TCP"
timeout_sec = 10
enable_cdn = false
backend {
group = google_compute_instance_group.default.self_link
balancing_mode = "UTILIZATION"
max_utilization = 1
}
health_checks = [google_compute_health_check.default.self_link]
security_policy = google_compute_security_policy.default.self_link
}
Frontend
TCPのターゲットプロキシとフォーワーディングルールを追加し、バックエンドにアクセスできるようにします。
ここでもどちらもTCPプロトコルのものを使用します。
resource "google_compute_target_tcp_proxy" "default" {
name = "tcp-lb-target-proxy"
backend_service = google_compute_backend_service.default.self_link
}
resource "google_compute_global_forwarding_rule" "default" {
name = "tcp-lb-forwarding-rule"
target = google_compute_target_tcp_proxy.default.self_link
ip_protocol = "TCP"
ip_version = "IPV4"
port_range = "8099-8099"
}
確認
アクセスしてみます。
$ curl xx.xxx.xxx.xxx:8099
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>Welcome to CentOS</title>
<style rel="stylesheet" type="text/css">
・・・・・
アクセスできました。
今度はgoogle_compute_security_policy.default.rule[0].actionで指定した許可設定を拒否設定deny(403)にします。
$ curl xx.xxx.xxx.xxx:8099
curl: (52) Empty reply from server
拒否されました。
気づいたこと
当たり前といえば当たり前ですが、HTTP(S) LB ではHTTP Status Code を指定し返すことができましたが、TCP LB ではStatus Code の指定をしても意味がありませんでした。
またバックエンドサービスはTCPプロトコルのものを使用しているためにログの有効化をすることができません。
そのためCloud Loggingからどのルールによって拒否されているかの特定が困難となります。
しかしながら、DDoS攻撃はある程度防いでくれるためサポートされることはとてもありがたいです。
株式会社grasys(グラシス)は、技術が好きで一緒に夢中になれる仲間を募集しています。
grasysは、大規模・高負荷・高集積・高密度なシステムを多く扱っているITインフラの会社です。Google Cloud (GCP)、Amazon Web Services (AWS)、Microsoft Azureの最先端技術を活用してクラウドインフラやデータ分析基盤など、ITシステムの重要な基盤を設計・構築し、改善を続けながら運用しています。
お客様の課題解決をしながら技術を広げたい方、攻めのインフラ技術を習得したい方、とことん技術を追求したい方にとって素晴らしい環境が、grasysにはあります。
お気軽にご連絡ください。
