Elastic 即代码：自动化的不只是基础设施
作者：来自 Elastic kylerozanitis
Elastic 即代码：自动化不只是基础设施
Terraform 是工程师常用的工具，用来通过一种叫 Infrastructure as Code（ IaC ）的模式创建、修改和删除基础设施。它通常用于管理云资源，比如应用负载均衡器（ ALB ）、数据库和虚拟机，但它同样也可以用来管理 Elastic 集群。不过，在很多 Elastic 环境中，集群创建之后的所有事情都发生在 Kibana 里 —— 索引模板、索引生命周期管理（ ILM ）策略、检测规则等等。
这会导致没有源码控制、无法回滚变更、无法进行漂移检测，也没有关于谁在什么时候、为什么修改了什么的审计记录。
Elastic 是一个 API 驱动的平台，这意味着你在 Kibana 中几乎能做的所有事情，也都可以通过 APIs 来完成。这表示我们不仅可以把基础设施作为代码来管理，还可以把更多内容代码化，从而获得可复现的环境、可审计性，以及对整个技术栈的信心。
在今天的博客中，我将展示如何只用一条 terraform apply 命令，就能创建一个 Elastic Cloud 集群、一个 ILM 策略、一个索引模板以及一个检测规则 —— 所有内容都在 Git 中进行版本控制。
理念
当你刚开始使用 Elastic、学习某个功能如何工作，或者调试一个用于 detection rule 的 ES|QL 查询时，Kibana 非常好用。但最终的目标，应该是尽可能把所有东西都作为代码来管理。这让你可以自由实验，同时仍然能够 rollback 到一个可用的版本。它也确保从 DEV 到 PROD 的变更是经过 review 和 approval 的。就像发布一个新的应用代码版本可能是灾难性的，对 Security Operations Center ( SOC ) 中运行的 detection rule 进行修改，同样可能非常危险。
Elastic 为平台的几乎每一个部分都暴露了 API。因此，通过结合 Terraform Elastic Cloud Provider 和 Elastic Stack Provider，我们可以构建一个可复现的 Elastic-as-Code 工作流，用来部署一个 cloud cluster、ILM 策略、index template，以及 detection rule。
第 1 步：部署一个 Elastic Cloud 集群
使用 Elastic Cloud provider，在你的根 main.tf 文件中定义一个 ec_deployment resource：
resource "ec_deployment" "demo" { name = "advent-demo" region = "us-east-1" version = "9.2.2" deployment_template_id = "aws-cpu-optimized-faster-warm-arm" elasticsearch = { hot = { autoscaling = {} } } kibana = { topology = {} } }这会创建一个完全托管的 Elastic Cloud 部署。请注意，即使没有显式指定 hot 层节点规格，仍然需要包含hot = { autoscaling = {} }。关于部署模板的更多信息，可以参考 Deployment templates 文档。
第 2 步：定义一个 ILM 策略
使用 Elasticstack provider，通过elasticstack_elasticsearch_index_lifecycle资源来定义一个 ILM 策略：
resource "elasticstack_elasticsearch_index_lifecycle" "advent_logs_ilm" { name = "advent-logs-ilm" delete { min_age = "30d" delete {} } }为了简单起见，这个 ILM 策略会将数据保留在 hot 层 30 天，然后删除。用代码来管理 ILM 策略非常有价值，因为改动可能会对数据以及整个集群健康产生连锁影响。想象这样一个场景：一位工程师决定添加一个 cold 层，设置为 1 个 primary shard 和 1 个 replica shard，但实际上只有一个 cold 节点。你可以想象，很快就会开始看到警告。
第 3 步：绑定 ILM 的 Index Template
在这一步中，我们将使用 elasticstack_elasticsearch_index_template 资源来定义我们的 index template，并引用前一步中定义的 ILM 策略：
resource "elasticstack_elasticsearch_index_template" "advent_logs_template" { name = "advent-logs-template" index_patterns = ["advent-logs-*"] priority = 200 template { settings = jsonencode({ index = { lifecycle = { name = "advent-logs-ilm" } } }) mappings = jsonencode({ properties = { "@timestamp" = { type = "date" } "message" = { type = "text" } "user" = { type = "keyword" } } }) } }步骤 4：检测规则
作为一个经常使用检测规则来处理从传统 SIEM 到更复杂欺诈用例的人来说，Discover 和 Kibana Detection Rules 是一个强大的组合，但一旦你确定了最终配置，最好使用 elasticstack_kibana_security_detection_rule 资源把它存储到 Git 中：
resource "elasticstack_kibana_security_detection_rule" "failed_login_rule" { name = "Multiple Failed Logins (Elastic as Code demo)" description = "Detects multiple failed login events in advent-logs indices for the Elastic-as-Code demo." rule_id = "advent-multiple-failed-logins" # Detection logic type = "query" query = "event.action:\"failed-login\"" language = "kuery" index = ["advent-logs-*"] # Scheduling from = "now-5m" to = "now" interval = "5m" # Risk/severity severity = "medium" risk_score = 50 # Misc metadata enabled = true tags = ["terraform", "advent-demo", "elastic-as-code"] author = ["Kyle Rozanitis"] # Human context field license = "Elastic License v2" false_positives = ["Legitimate user mistyping their password during normal usage"] references = ["https://elastic.github.io/detection-rules-explorer/"] note = "Investigate source IP, username, and host. Check for brute force behavior." setup = "Ensure authentication events are indexed into 'advent-logs-*'." }第 5 步：让一切真正运行起来
你的代码仓库现在看起来应该像这样：
├── main.tf ├── ilm.tf ├── template.tf ├── rule.tf现在只需运行：
terraform applyTerraform 会创建：
- 一个新的 Elastic Cloud 集群
- 一个 ILM 策略
- 一个与该 ILM 策略关联的索引模板
- 一个检测规则
这就是 Elastic 平台应有的使用方式。
结语
如果你看到这里，感谢阅读！所有内容都可以在名为 elastic-as-code 的 GitHub 仓库中找到。只需克隆仓库，创建一个 Elastic Cloud API key 并获取你的 Organization ID，将它们添加到 .env 文件中，安装 Terraform，然后运行 terraform apply。
今天的目标是展示如何用 Terraform 管理远不止云基础设施。在我的个人环境中，我甚至会进一步创建 JSON 文件来管理尚未有 Terraform 资源的功能，比如异常检测任务。由于 Elastic 在 Kibana 和 API 之间提供了功能一致性，你可以轻松自动化创建其余资源。
能够回滚错误更改、在更新前进行同行评审、通过分支从 DEV → STAGING → PROD、检测平台漂移，以及用单条命令重建整个栈，这些都是非常强大的能力。
自动化愉快，节日快乐！
原文：https://discuss.elastic.co/t/dec-7th-2025-en-elastic-as-code-automating-more-than-just-infrastructure/383587