By Kevin Hospodar, Go-to-Market Leader, River Point Technology

IBM made an announcement this week that I think deserves more than a quick read and a LinkedIn like. They are expanding their enterprise security program for the AI era and joining Project Glasswing, an industry coalition built to protect critical software infrastructure. It is worth paying attention to. Not because it is surprising, but because it lines up exactly with what we have been telling clients for years. The organizations that win with AI are the ones that treat security and infrastructure as a strategy from the start, not something they bolt on later.

At River Point, we have worked with hundreds of enterprises on this exact problem. We are IBM’s longest-standing HashiCorp partner and have been recognized as Partner of the Year multiple years running. That is not a credential I drop to sound impressive. It means we have been in this space longer than almost anyone, through multiple platform shifts, and we have seen what works and what does not. That experience now shapes how we help clients navigate the broader IBM automation and security ecosystem.

IBM’s announcement leans on three pillars. I want to add some real context to each one, because awareness is not a plan.

1. You Cannot Secure Infrastructure You Have Not Standardized

IBM Concert is built to bring application, infrastructure, and network signals together into one operational view. The goal is to move organizations from watching dashboards to actually responding in a coordinated way. Good idea. But here is what I see when I walk into enterprise environments: the tooling is rarely the bottleneck.

The gap is almost always inconsistent infrastructure provisioning. Manual deployments. Undocumented resources. Configuration drift nobody is tracking. Those are the attack surfaces AI-powered attackers are now learning to find faster than your team can patch them.

Terraform, which is now part of the IBM automation platform, is how serious enterprises close that gap. When every resource is provisioned through code, reviewed through policy, and tracked through state, Concert actually has clean signal to work with. The visibility tools get smarter when the infrastructure underneath them is trustworthy.

Ask yourself: does your team have full visibility into what is running, where it lives, and who provisioned it? Or are you relying on security tools to find what better processes should have prevented in the first place?

2. Your Hybrid Cloud Footprint Is an Attack Surface. Treat It Like One.

IBM called out hybrid cloud environments across more than 175 countries as the landscape they are defending. That is the world most of our clients live in too. Multi-cloud, on-premises, edge deployments spread across regions and business units. The perimeter is gone. Identity is the boundary now.

This is where secrets management stops being a nice-to-have. HashiCorp Vault, now integrated into the IBM ecosystem, is the standard for dynamic secrets, certificate management, and zero-trust access at enterprise scale. When credentials are short-lived, automatically rotated, and tied to machine identity rather than someone’s memory or a config file, the damage from any breach shrinks considerably.

We have helped organizations move away from static, long-lived credentials scattered across pipelines and configuration files. The security improvement is real, but so is the operational relief. Developers and operators stop carrying the mental load of managing secrets manually. That matters more than people admit.

Here is the uncomfortable truth. AI-powered attacks are going after the credentials your team forgot about. The ones sitting in that old CI/CD pipeline. The ones in a config file from three years ago. Vault closes that door.

3. Running Open Source Without Enterprise Support Is a Risk Decision

IBM and Red Hat made a point of highlighting their commitment to maintaining enterprise-grade open source components, proactive patching, and rapid response when issues surface. That framing resonates with me because it mirrors exactly the conversation I have with clients about their HashiCorp deployments.

Moving from community-tier to enterprise is not about paying for something that used to be free. It is about buying certainty. Self-managed, community HashiCorp deployments carry real operational risk. Delayed patches. Unsupported configurations. No SLA when something breaks during a critical deployment at two in the morning. HCP, the HashiCorp Cloud Platform, is managed Vault and managed Terraform with the operational rigor that enterprise security teams actually need.

As IBM has brought HashiCorp into its automation platform strategy, there are real questions clients need to work through around existing deployments, licensing, and roadmap. River Point has been navigating HashiCorp transitions longer than any other partner in this ecosystem. That matters right now.

AI Is a Strategy. Not a Product.

IBM’s Project Glasswing framing gets this right. It is not about one vendor’s tool. It is about an entire ecosystem hardening itself against a new class of threat. I believe the same thing about AI more broadly.

The organizations approaching AI with a clear infrastructure, security, and governance foundation will keep pulling ahead. The ones treating it as a collection of point solutions will accumulate risk at the same rate they accumulate capability. I have watched that play out enough times to say it with confidence.

We built River Point’s practice around helping enterprises get in front of this, not respond to it after something breaks.

If IBM’s announcement started a conversation in your organization about where you actually stand, that conversation is worth continuing with us. We run executive briefings and working sessions built to assess your current state, identify what matters most, and build a path forward that is specific to your environment. No generic frameworks. Just direct counsel from a team that has done this across hundreds of organizations.

Reach out if you want to talk.

River Point Technology is IBM’s longest-standing and most successful HashiCorp partner, recognized as Partner of the Year across multiple consecutive years. We help enterprises design, implement, and operate secure infrastructure at scale across the IBM and HashiCorp portfolio.

Many organizations using the Ansible Automation Platform (AAP) still provision virtual machines manually and then run playbooks afterward. That process often involves waiting for infrastructure tickets, scheduling jobs, and completing lengthy configuration steps. In some cases, it can take hours or even days for a system to be ready for use.

Packer can communicate with both the cloud and the hypervisor, as well as a provisioner, changing the workflow to mint golden images. Deployments begin with a system that is ready in minutes, not days. Although it includes native Ansible support, Enterprise architects often point out problems right away: “You are bypassing all the governance we have built around AAP. No centralized logging, no RBAC, no audit trails, and no consistent execution environments.” For teams that rely on AAP for governance and standardized workflows, local Ansible runs create silos or force duplication. To address this, a custom Packer provisioner was built to integrate directly with the AAP API. Instead of running Ansible locally, Packer now calls job templates from AAP during image builds, enabling organizations to continue using their existing playbooks and environments while benefiting from the speed and repeatability of image factories.

With this approach, image builds run under the same governance as production workloads and benefit from centralized logging, RBAC, and consistent execution environments. Concerns about bypassing controls disappear since all automation stays inside AAP. The result is faster provisioning, reusable images, and an automation workflow that feels both modern and enterprise-ready.

Using the Provisioner

First the plugin will need to be added to the required plugins:

packer {
  required_plugins {
    ansible-aap = {
      source  = "github.com/rptcloud/ansible-aap"
      version = "1.0.0"
    }
  }
}

Then within the build spec, the provisioner can be configured to your AAP instance, assigned a job template ID, and all API orchestration occurs within the code. In a packer template, it would look something like:

build {
  sources = ["source.amazon-ebs.example"]

  provisioner "ansible-aap" {
    tower_host          = "https://aap.example.com"
    access_token        = vault("secret/data/aap", "access_token")
    job_template_id     = 11 # Job template to install docker on host
    organization_id     = 1

    dynamic_inventory   = true

    extra_vars = {
      Name        = "packer-ansible-demo"
      Environment = "production"
      BuiltBy     = "packer"
    }

    timeout       = "15m"
    poll_interval = "10s"
  }
}

amazon-ebs.example: output will be in this color.

==> amazon-ebs.example: Prevalidating any provided VPC information
==> amazon-ebs.example: Prevalidating AMI Name: packer-ansible-demo-20250820181254
...
==> amazon-ebs.example: Waiting for SSH to become available...
==> amazon-ebs.example: Connected to SSH!
==> amazon-ebs.example: Setting a 15m0s timeout for the next provisioner...
    amazon-ebs.example: 🌐 Attempting to connect to AAP server: https://aap.example.com
    amazon-ebs.example: 🔧 Initializing AAP client...
    amazon-ebs.example: ✅ AAP client initialized successfully
    amazon-ebs.example: 🎯 Creating inventory for target host: 54.146.55.206
    amazon-ebs.example: 🗄️ Using organization ID: 1
    amazon-ebs.example: ✅ Created inventory with ID: 75
    amazon-ebs.example: ✅ Created SSH credential ID: 63
    amazon-ebs.example: 🖥️ Adding host 54.146.55.206 to inventory
    amazon-ebs.example: ✅ Added host ID: 66
    amazon-ebs.example: 🚀 Launching job template ID 10 for target_host=54.146.55.206
    amazon-ebs.example: ✅ Job launched https://aap.example.com/execution/jobs/playbook/142/output/. Waiting for completion...
    amazon-ebs.example: ⏳ Polling job status...
    amazon-ebs.example: 🎉 Job completed successfully!
    amazon-ebs.example: Identity added: /runner/artifacts/142/ssh_key_data (packer-aap-key)
    amazon-ebs.example: 
    amazon-ebs.example: PLAY [Install Docker] **********************************************************
    amazon-ebs.example: 
    amazon-ebs.example: TASK [Gathering Facts] *********************************************************
    amazon-ebs.example: [WARNING]: Platform linux on host 54.146.55.206 is using the discovered Python
    amazon-ebs.example: interpreter at /usr/bin/python3.7, but future installation of another Python
    amazon-ebs.example: interpreter could change the meaning of that path. See
    amazon-ebs.example: https://docs.ansible.com/ansible-
    amazon-ebs.example: core/2.16/reference_appendices/interpreter_discovery.html for more information.
    amazon-ebs.example: ok: [54.146.55.206]
    amazon-ebs.example: 
    amazon-ebs.example: TASK [Update package cache] ****************************************************
    amazon-ebs.example: ok: [54.146.55.206]
    amazon-ebs.example: 
    amazon-ebs.example: TASK [Install Docker] **********************************************************
    amazon-ebs.example: changed: [54.146.55.206]
    amazon-ebs.example: 
    amazon-ebs.example: TASK [Start and enable Docker service] *****************************************
    amazon-ebs.example: changed: [54.146.55.206]
    amazon-ebs.example: 
    amazon-ebs.example: TASK [Add ec2-user to docker group] ********************************************
    amazon-ebs.example: changed: [54.146.55.206]
    amazon-ebs.example: 
    amazon-ebs.example: PLAY RECAP *********************************************************************
    amazon-ebs.example: 54.146.55.206              : ok=5    changed=3    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
    amazon-ebs.example: 🧹 Cleaning up credential 63...
    amazon-ebs.example: 🧹 Cleaning up host 66...
    amazon-ebs.example: 🧹 Cleaning up inventory 75...
==> amazon-ebs.example: Stopping the source instance...
 ...
Build 'amazon-ebs.example' finished after 4 minutes 45 seconds.

==> Wait completed after 4 minutes 45 seconds

==> Builds finished. The artifacts of successful builds are:
--> amazon-ebs.example: AMIs were created:
us-east-1: ami-0d056993e3e2be56f

How the Plugin Integration Works

AAP has a well-documented REST API. The provisioner handles the entire lifecycle through API calls. Here’s the workflow:

sequenceDiagram
    participant P as Packer
    participant Prov as AAP Provisioner
    participant AAP as Ansible Automation Platform
    participant VM as Target VM
    P->>Prov: Start provisioning
    Prov->>AAP: Create temporary inventory
    AAP-->>Prov: Inventory ID: 123
    Prov->>AAP: Register target host
    AAP-->>Prov: Host ID: 456
    Prov->>AAP: Create SSH/WinRM credential
    AAP-->>Prov: Credential ID: 789
    Prov->>AAP: Launch job template
    AAP-->>Prov: Job ID: 1001
    loop Poll Status
        Prov->>AAP: Check job status
        AAP-->>Prov: Status: running/successful/failed
    end
    AAP->>VM: Execute playbooks
    VM-->>AAP: Configuration complete
    Prov->>AAP: Delete credential
    Prov->>AAP: Delete host  
    Prov->>AAP: Delete inventory
    Prov-->>P: Provisioning complete

1. Dynamic Inventory Creation

First, we create a temporary inventory in AAP. Every build receives its temporary inventory with a timestamp, ensuring no conflicts or stepping on other builds, providing clean isolation.

curl -X POST https://aap.example.com/api/controller/v2/inventories/ \
  -H "Authorization: Bearer $AAP_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "packer-inv-1642684800",
    "description": "Temporary inventory for packer provisioning",
    "organization": 1
  }'

Response:

{
  "id": 123,
  "name": "packer-inv-1642684800",
  "organization": 1,
  "created": "2025-01-20T10:00:00Z"
}

2. Host Registration

Next, we register the target host that Packer is building. In the provisioner, we retrieve all connection details directly from Packer’s communicator. SSH keys, passwords, WinRM creds, whatever Packer is using to talk to the instance:

curl -X POST https://aap.example.com/api/controller/v2/hosts/ \
  -H "Authorization: Bearer $AAP_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "10.0.1.100",
    "inventory": 123,
    "variables": "{\"ansible_host\": \"10.0.1.100\", \"ansible_port\": 22, \"ansible_user\": \"ec2-user\"}"
  }'

Response:

{
  "id": 456,
  "name": "10.0.1.100",
  "inventory": 123,
  "variables": "{\"ansible_host\": \"10.0.1.100\", \"ansible_port\": 22, \"ansible_user\": \"ec2-user\"}"
}

3. Dynamic Credential Management

Each build has the option to use a temporary credential provided to AAP; this refers to SSH key or username/password authentication.

curl -X POST https://aap.example.com/api/controller/v2/credentials/ \
  -H "Authorization: Bearer $AAP_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "packer-ssh-cred-1642684800",
    "description": "SSH credential for Packer builds",
    "credential_type": 1,
    "organization": 1,
    "inputs": {
      "username": "ec2-user",
      "ssh_key_data": "-----BEGIN PRIVATE KEY-----\nMIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQC..."
    }
  }'

Response:

{
  "id": 789,
  "name": "packer-ssh-cred-1642684800",
  "credential_type": 1,
  "organization": 1
}

4. Job Orchestration

Finally, we launch the actual job template. For this integration to work properly, your job template in AAP needs to be configured to accept runtime parameters:

{
  "name": "Packer Image Build Template",
  "ask_inventory_on_launch": true,
  "ask_credential_on_launch": true,
  "ask_variables_on_launch": true
}

The ask_inventory_on_launch and ask_credential_on_launch settings are crucial – they allow the provisioner to inject the temporary inventory and credentials at launch time instead of using pre-configured values. Without these settings, the job template would try to use its default inventory and credentials, which won’t have access to your Packer-managed instance.

Here’s the launch request:

curl -X POST https://aap.example.com/api/controller/v2/job_templates/42/launch/ \
  -H "Authorization: Bearer $AAP_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "inventory": 123,
    "credentials": [789],
    "extra_vars": {
      "environment": "production",
      "packer_build_name": "amazon-linux-base",
      "packer_build_id": "build-1642684800"
    }
  }'

Response:

{
  "job": 1001,
  "ignored_fields": {},
  "id": 1001,
  "type": "job",
  "url": "/api/controller/v2/jobs/1001/",
  "status": "pending"
}

Then we poll the job status until completion:

curl -X GET https://aap.example.com/api/controller/v2/jobs/1001/ \
  -H "Authorization: Bearer $AAP_TOKEN"

Response when complete:

{
  "id": 1001,
  "status": "successful",
  "finished": "2025-01-20T10:15:30Z",
  "elapsed": 330.5
}

Automated Resource Lifecycle Management

One of the more critical steps is to ensure that temporary resources are cleaned up. Nothing worse than finding 500 orphaned inventories in AAP because builds crashed. The provisioner is coded to track and clean up in a dependency-safe cleanup process:

# Delete credential first
curl -X DELETE https://aap.example.com/api/controller/v2/credentials/789/ \
  -H "Authorization: Bearer $AAP_TOKEN"

# Then delete the host (depends on credential being removed)
curl -X DELETE https://aap.example.com/api/controller/v2/hosts/456/ \
  -H "Authorization: Bearer $AAP_TOKEN"

# Finally delete the inventory (depends on hosts being removed)
curl -X DELETE https://aap.example.com/api/controller/v2/inventories/123/ \
  -H "Authorization: Bearer $AAP_TOKEN"

Get Started

Ready to integrate your Packer workflows with AAP? The provisioner is open source and available on GitHub. Check out the repository for installation instructions, configuration examples, and contribution guidelines:

rptcloud/packer-plugin-ansible-aap

If you’re using this provisioner in your environment or have ideas for improvements, contributions and feedback are welcome!

River Point Technology (RPT), an award-winning cloud consulting, training, and enablement provider, is thrilled to announce that we have been named HashiCorp’s Americas SI Partner of the Year for 2024. This prestigious recognition highlights our ongoing dedication to helping enterprises maximize their technology investments through HashiCorp’s suite of multi-cloud infrastructure automation tools. It also underscores RPT’s relentless commitment to empowering the Fortune 500 to redefine the art of the possible in cloud automation and management.  

Sean Toomey, Senior Director, Partners, at HashiCorp, had this to say about the recognition, “River Point Technology has demonstrated a significant commitment to HashiCorp through substantial investments in sales, services, and training.” 

He then added, “Notably, River Point Technology is distinguished as one of the few partners holding all three core competencies—Infrastructure, Security, and Networking. They also play a critical role in testing and piloting new products and features, reflecting their proactive involvement in innovation. Their expertise is especially vital in managing some of our most significant Strategic Accounts.” 

River Point Technology founder and CEO, Jeff Eiben, highlighted the benefits of the relationship to organizations. “Our partnership with HashiCorp has allowed us to simplify infrastructure automation for our clients, enabling faster, more efficient deployment and scaling.” He went on to say, “Being recognized as the Americas SI Partner of the Year is a testament to our team’s expertise and our clients’ trust in us to deliver results.” 

Expertise and Accomplishments 

Indeed, the team is quite stacked when it comes to HashiCorp expertise. Beyond the competencies distinction, RPT can also boast more HashiCorp Ambassadors than any global partner including Core Contributors to the HashiCorp software. Recently, we earned the distinction of having the industry’s first and only experts to pass the challenging Terraform Professional Certification exam. Combined, these credentials ensure that our clients are in the hands of industry leading HashiCorp experts, fully equipped to guide them through their digital transformation journey. 

Innovative Solutions for Enterprise Clients 

To support RPT’s commitment to help clients succeed with HashiCorp products, we recently introduced RPT Bundles for Infrastructure and Security Lifecycle Management, that provide enterprises with tightly scoped, outcome-oriented services structured around HashiCorp Validated Designs (HVD). These bundles streamline the adoption, scaling, and operations of HashiCorp solutions. 

River Point Technology’s exclusive Accelerator program offers ongoing enablement that help clients accelerate their automation journey. Our expert advisors are there to empower and lead your team through every phase of adoption; from discovery to build to process and ongoing adoption. For resource enablement we deliver custom, private training for HashiCorp products, ensuring that our clients have the knowledge and tools necessary to thrive. 

Commitment to Excellence 

RPT’s unique combination of best-in-class services, leveraging our HashiCorp Ambassadors and certified experts, positions us to continue delivering exceptional results for organizations across the globe. From our proprietary Value Creation Technology (VCT) process to custom integrations and advanced solutions, we empower enterprises to ‘think big, start small, and scale fast.’ 

As we congratulate our entire team on all their efforts that have helped us earn the prestigious HashiCorp Americas SI Partner of the Year award, we remain focused on delivering cutting-edge, human-centered solutions that empower our clients to achieve sustainable growth and success across their multi-cloud environments. We look forward to strengthening our relationship with HashiCorp further and proudly collaborate with other notable companies such as AWS, IBM, SUSE, Microsoft, Google Cloud, and more.  This broad, technology-agnostic approach allows us to support our clients’ diverse digital transformation and cloud automation needs. 

For more information, please contact our team today.