Add support for Elastic IP pool in AWS deployments#524
Conversation
Add support for using pre-allocated Elastic IP pools instead of randomly created EIPs. This allows CI/CD runners and external systems to whitelist specific IP addresses for SSH access, improving security by avoiding 0.0.0.0/0 firewall rules. Changes: Base Modules: - Add optional eip_allocation_id parameter to sonar-base-instance, dam-base-instance, ciphertrust-manager, cte-ddc-agent, and dra-admin - When eip_allocation_id is provided, use existing EIP instead of creating new - When null (default), create and manage new EIP (backward compatible) Wrapper Modules: - Add pass-through eip_allocation_id parameter to hub, mx, agentless-gw, and agent-gw modules Deployment Example: - Add use_eip_pool and eip_pool_tag variables - Add eip_pool.tf with pool query logic and allocation ID distribution - Add validation to ensure sufficient IPs are available in pool - Add time_sleep resource to handle CipherTrust provider timing with pooled EIPs - Update all module calls to pass allocation IDs when pooled mode enabled Benefits: - Predictable IP addresses for CI/CD firewall whitelisting - IPs survive terraform destroy and can be reused - Fully backward compatible (default behavior unchanged) - Deployment-level pool management (base modules stay simple) Co-Authored-By: Claude <noreply@anthropic.com>
elsegev
changed the title
|
|
||
| filter { | ||
| name = "tag:Pool" | ||
| values = [var.eip_pool_tag] |
There was a problem hiding this comment.
I know you wrote a comment that we expect the user to only give us unassociated ids, but maybe we can filter out already associated EIPs and catch user errors with validation instead of during runtime?
something like:
filter {
name = "association-id"
values = [""] # Empty association-id means unassociated
}
| # Distribute allocation IDs to resources | ||
| # Use null if use_eip_pool is false (modules will create new EIPs) | ||
|
|
||
| # Index counter for distributing IPs |
There was a problem hiding this comment.
can we change the way we distribute the EIPs and make it more robust?
currently the calculated indices will shift whenever the deployment configuration changes.
this also applies to the CM agents map.
maybe we can keep a fixed and stable allocation.
| data "aws_eips" "pool" { | ||
| count = var.use_eip_pool ? 1 : 0 | ||
|
|
||
| filter { |
There was a problem hiding this comment.
what happens if there multiple deployment with the same eip_pool_tag competing for the same EIPs?
maybe we can document this limitation
| } : {} | ||
| } | ||
|
|
||
| # Validation check |
There was a problem hiding this comment.
maybe we can check in here that the EIPs' availability and not just quantity, checking there are all unassociated and logging the result to the user.
3 participants
No description provided.