Elastic Stack Terraform 提供商达到了一个重要的里程碑。从 v0.13.1 版开始,您可以管理 Elastic 安全态势,包括检测规则、异常列表和预建规则,以及 ML 异常检测作业、合成监控器和人工智能连接器,所有这些都以代码的形式进行管理。
这样就能将检测逻辑和 ML 作业与核心集群纳入同一版本化、同行评审的工作流程。它可确保您的安全态势和人工智能连接器不再是自动化环境中的人工异常值。
挑战:大规模的安全性和可观测性配置
随着弹性部署的增加,管理它们的复杂性也在增加。安全团队维护着数以百计的检测规则。SRE 配置跨数十个集群的监控。ML 工程师在多个环境中调整异常检测工作。所有这些配置都必须是一致的、可审计的和可重复的。
如果没有 "基础设施即代码",团队就会面临两个问题:
-
配置漂移。规则、策略和监控器是通过 Kibana UI 手动创建的。随着时间的推移,制作和分期出现了偏差。没有人知道哪一个版本的检测规则在哪里运行。
-
隐藏的审计线索。当检测规则发生变化或添加了异常情况时,没有拉取请求需要审核,没有提交历史需要跟踪,也没有回滚路径(如果出现故障)。用户需要付出额外的努力才能访问这些历史记录。
Elastic Stack Terraform 提供商通过将这些配置引入团队已经用于基础设施的相同版本控制、同行评审工作流程,解决了这一问题。
作为代码的安全工件:检测规则、异常和预置规则
现在,您可以通过 Terraform 管理 Elastic Security 检测规则的整个生命周期。
检测规则
elasticstack_kibana_security_detection_rule 资源可让您以HashiCorp 配置语言(HCL) 格式定义、版本和部署检测规则:
resource "elasticstack_kibana_security_detection_rule" "suspicious_admin_logon" {
name = "Suspicious Admin Logon Activity"
type = "query"
query = "event.action:logon AND user.name:admin"
language = "kuery"
enabled = true
description = "Detects suspicious admin logon activities"
severity = "high"
risk_score = 75
from = "now-6m"
to = "now"
interval = "5m"
tags = ["security", "authentication", "admin"]
}
这意味着您的检测规则将在 Git 中存活,接受代码审查,并在不同环境中一致部署。无需再点击 Kibana UI,即可将规则从暂存复制到生产。
例外清单和项目
安全即代码的故事延伸到一整套异常管理资源:
elasticstack_kibana_security_exception_list- 创建和管理例外情况列表elasticstack_kibana_security_exception_item- 在列表中定义单个异常项elasticstack_kibana_security_list和elasticstack_kibana_security_list_item- 管理 IP 允许列表、文件哈希值和其他指标的值列表elasticstack_kibana_security_list_data_streams- 将列表与特定数据流关联
下面是一个将它们联系在一起的示例--异常列表,其中的项目可抑制检测规则的已知误报:
resource "elasticstack_kibana_security_exception_list" "vuln_scanner_exceptions" {
list_id = "vuln-scanner-exceptions"
name = "Vulnerability Scanner Exceptions"
description = "Suppress alerts from authorized vulnerability scanners"
type = "detection"
namespace_type = "single"
tags = ["security", "vulnerability-scanning"]
}
resource "elasticstack_kibana_security_exception_item" "nessus_scanner" {
list_id = elasticstack_kibana_security_exception_list.vuln_scanner_exceptions.list_id
item_id = "nessus-scanner"
name = "Nessus Scanner - Authorized"
description = "Suppress alerts from authorized Nessus scanner hosts"
type = "simple"
namespace_type = "single"
entries = [
{
type = "match"
field = "source.ip"
operator = "included"
value = "10.0.50.10"
},
{
type = "match_any"
field = "process.name"
operator = "included"
values = ["nessus", "nessusd"]
}
]
tags = ["nessus", "authorized-scanner"]
}
resource "elasticstack_kibana_security_exception_item" "qualys_scanner" {
list_id = elasticstack_kibana_security_exception_list.vuln_scanner_exceptions.list_id
item_id = "qualys-scanner"
name = "Qualys Scanner - Authorized"
description = "Suppress alerts from authorized Qualys scanner subnet"
type = "simple"
namespace_type = "single"
entries = [
{
type = "match"
field = "source.ip"
operator = "included"
value = "10.0.51.0/24"
}
]
tags = ["qualys", "authorized-scanner"]
}
异常列表及其项通过list_id 链接,因此 Terraform 会自动管理依赖关系图。添加新的授权扫描仪只需单行 PR,无需点击 Kibana UI,也不会忘记哪个环境获得了更新。
预制安全规则
elasticstack_kibana_prebuilt_rule 资源可让您通过 Terraform 管理 Elastic 的预构建检测规则。这对于需要跟踪哪些预置规则已启用、自定义其参数并确保跨环境一致部署的组织来说尤其有价值。
作为代码的 ML 异常检测
机器学习异常检测是 Elasticsearch 最强大的功能之一,但跨环境管理 ML 作业传统上一直是一个手动过程。你在 Kibana UI 中创建一个任务,调整检测器,配置数据源,然后希望有人记录这些设置,以便在下一个环境中复制。
elasticstack_elasticsearch_ml_anomaly_detection_job 资源改变了这一状况。现在,您可以在 HCL 中定义异常检测任务的全部配置,包括检测器、桶范围、影响因素、数据源和分析限制,并在开发、暂存和生产过程中统一部署。
resource "elasticstack_elasticsearch_ml_anomaly_detection_job" "cpu_anomalies" {
job_id = "high-cpu-by-host"
description = "Detect unusual CPU usage patterns"
analysis_config = {
bucket_span = "15m"
detectors = [{
function = "high_mean"
field_name = "system.cpu.user_pct"
}]
influencers = ["host.name"]
}
data_description = {
time_field = "@timestamp"
}
}
这对于依靠人工智能捕捉基础设施异常、异常用户行为或安全威胁的团队来说非常重要。在启动新集群或从故障中恢复时,无需手动重新创建作业,而是将整个 ML 配置保存在版本控制中--可审查、可重复、可恢复。
使用 API 密钥实现跨集群自动化
对于运行多个 Elasticsearch 集群的企业,提供商现在支持用于跨集群搜索(CCS)和跨集群复制(CCR)的集群 API 密钥。您可以创建专为跨集群安全通信而设计的 API 密钥,从而实现多集群架构的端到端自动化。
这意味着你可以在一个 Terraform 配置中配置两个集群,在它们之间配置 CCS/CCR,并设置必要的安全凭证。
resource "elasticstack_elasticsearch_security_api_key" "ccs_key" {
name = "cross-cluster-search-key"
type = "cross_cluster"
access = {
search = [{
names = ["logs-*", "metrics-*"]
}]
replication = [{
names = ["archive-*"]
}]
}
expiration = "90d"
metadata = jsonencode({
environment = "production"
purpose = "ccs-ccr-between-prod-clusters"
team = "platform"
})
}
当type 设置为cross_cluster 时,API 密钥的作用域为 CCS/CCR 操作。您可以定义哪些索引模式可用于搜索和复制,设置过期策略,并用元数据标记密钥--所有这些都可在拉取请求中审查。
在文档中了解有关API 密钥资源的更多信息。
作为代码的人工智能连接器
该提供商现在支持.bedrock 和.gen-ai 连接器,将人工智能基础架构引入 Terraform 工作流程。随着团队越来越多地将大型语言模型集成到 Elastic 工作流中(用于人工智能助手、攻击发现和自动调查),将这些连接器配置作为代码进行管理变得至关重要。
resource "elasticstack_kibana_action_connector" "bedrock" {
name = "aws-bedrock"
connector_type_id = ".bedrock"
config = jsonencode({
apiUrl = "https://bedrock-runtime.us-east-1.amazonaws.com"
defaultModel = "anthropic.claude-v2"
})
secrets = jsonencode({
accessKey = var.aws_access_key
secret = var.aws_secret_key
})
}
resource "elasticstack_kibana_action_connector" "openai" {
name = "openai"
connector_type_id = ".gen-ai"
config = jsonencode({
apiProvider = "OpenAI"
apiUrl = "https://api.openai.com/v1/chat/completions"
defaultModel = "gpt-4"
})
secrets = jsonencode({
apiKey = var.openai_api_key
})
}
在 Terraform 中定义了这些连接器后,您就可以将人工智能集成配置与 Elastic 基础架构的其他部分一起进行版本升级,并通过简单的 PR 交换模型或提供商。
可观察性增强
合成监测器
elasticstack_kibana_synthetics_monitor 资源现在包括一个labels 字段,可以更好地组织和过滤合成检查。通过标签,您可以按团队、环境或服务对监控器进行标记,从而更轻松地管理大规模合成监控。
更多平台改进
最近发布的版本还包括一些资源和属性,使提供商的覆盖范围更加完善:
elasticstack_elasticsearch_alias- 将 Elasticsearch 别名作为专用资源进行管理elasticstack_kibana_default_data_view- 设置 Kibana 空间的默认数据视图solutionelasticstack_kibana_space上的属性 - 为 Kibana 空间配置解决方案类型(从 8.16 起可用)- 舰队代理策略增强 -
host_name_format用于配置主机名与 FQDN,required_versions用于版本固定
开始使用
如果您已经在使用 Elastic Stack Terraform 提供商,请升级到最新的提供商版本,以获得所有这些功能:
terraform {
required_providers {
elasticstack = {
source = "elastic/elasticstack"
version = "~> 0.14"
}
}
}
如果你是使用 Terraform 管理弹性堆栈的新手,请从 Terraform 注册表上的提供程序文档开始。
要立即开始使用 Elastic Cloud,请登录Elastic Cloud 控制台或注册免费试用。
有关变更的全部内容,请查看GitHub 上的发布说明。
