Deploys an Event Hub Namespace with a list of event hubs connected to it. Each Event Hub can have a set of consumer groups and keys (authorization rules). Its recommended to create one consumer group per application / system that should process events.
It is not possible to create any hub key that have access to manage the hub. Management will be done with terraform templates and therefore not added as an input variable.
Example showing deployment of a namespace with single hub using tau
module {
source = "avinor/event-hubs/azurerm"
version = "1.1.0"
}
inputs {
name = "simple"
location = "westeurope"
resource_group_name = "events-simple-rg"
sku = "Standard"
hubs = [
{
name = "input"
partitions = 8
message_retention = 1
consumers = [
"app1",
"app2"
]
keys = [
{
name = "app1"
listen = true
send = false
},
{
name = "app2"
listen = true
send = true
}
]
}
]
}Output from module is the namespace_id, map of hubs and their id and a map of hubs and primary and secondary key for each entry in keys list.
For this simple example output would look like this:
namespace_id = /subscriptions/{subscriptionId}/resourceGroups/events-simple-rg/providers/Microsoft.EventHub/namespaces/simple-ns
hub_ids = {
"input" = "/subscriptions/{subscriptionId}/resourceGroups/events-simple-rg/providers/Microsoft.EventHub/namespaces/simple-ns/eventhubs/input"
}
keys = {
"app1" = {
"primary_key" = "DWEIB4wIpTd8obDP05CPGS8TjtQxCZmesONwW6LrOB4="
"secondary_key" = "..."
}
"app2" = {
"primary_key" = "...="
"secondary_key" = "..."
}
}Diagnostics settings can be sent to either storage account, event hub or Log Analytics workspace. The variable diagnostics.destination is the id of receiver, ie. storage account id, event namespace authorization rule id or log analytics resource id. Depending on what id is it will detect where to send. Unless using event namespace the eventhub_name is not required, just set to null for storage account and log analytics workspace.
Setting all in logs and metrics will send all possible diagnostics to destination. If not using all type name of categories to send.
High level checklist of compliance against NIST Cybersecurity Framework.
PR.AC-4: Access permissions are managed, incorporating the principles of least privilege and separation of duties
Assign least privilege possible when creating access keys. Only assign required privileges.
PR.AC-5: Network integrity is protected, incorporating network segregation where appropriate
Use network_rules to protect the namespace from unwanted access where possible. Bind to subnet where services consuming / producing data is located and restrict by ip if access is required outside Azure.
PR.DS-1: Data-at-rest is protected
https://docs.microsoft.com/en-us/azure/event-hubs/event-hubs-security-controls
PR.DS-2: Data-in-transit is protected
See above. Only encrypted channels supported.
AMQPs: https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-amqp-protocol-guide#basic-amqp-scenarios
Kafka: https://docs.microsoft.com/en-us/azure/event-hubs/event-hubs-for-kafka-ecosystem-overview#security-and-authentication
PR.IP-4: Backups of information are conducted, maintained, and tested periodically
Not using Capture as data are considered only valuable in short periods and not performing any backup of data.
DE.CM-7: Monitoring for unauthorized personnel, connections, devices, and software is performed
Use diagnostic settings to forward all logs for analysis.