IaCM Plugin for Internal Developer Portal
Connect IaCM workspaces to your IDP service catalog so developers can review provisioned resources, data sources, and outputs without leaving the developer portal.
The Harness IaCM plugin for Internal Developer Portal (IDP) surfaces infrastructure workspaces inside the IDP service catalog. Developers reviewing a service see the provisioned resources, data sources, and outputs for its workspace alongside the rest of that service's context, without switching to the IaCM module.
You connect a workspace to a catalog entity by adding one annotation to the entity's catalog-info.yaml definition. Harness reads that annotation, renders an IACM tab on the entity page, and links back to the full workspace for anyone who needs to run a plan or apply. The tab is read only, so opening it never changes infrastructure.
Before you begin
Harness account with IDP enabled: You need Internal Developer Portal in the module list. Go to Get started with IDP to set up the module.
A provisioned IaCM workspace: The workspace must have completed at least one successful apply, otherwise the tab renders empty. Go to Get started with IaCM to create and provision a workspace.
A registered catalog entity: You need an existing IDP catalog entity to attach the workspace to. Go to Register a software component to add one.
IaCM workspace permissions: You need View on Workspaces, and Access State if you want the state details to render. Go to the permissions reference to review these, and ask an administrator to assign a role that includes them using Manage roles.
Catalog entity permissions: You need edit access to the entity definition, whether it lives in Git or in the catalog. Go to IDP RBAC to review catalog permissions.
Connect a workspace to a service
Adding the harness.io/workspace-url annotation to a catalog entity is the only step required to render the IACM tab.
Get your workspace URL
The plugin reads the workspace identifiers out of the URL, so copy the URL rather than assembling it by hand:
Navigate to Infrastructure > Infrastructure as Code Management and open your workspace.
Select the Resources tab.
Copy the full URL from your browser address bar. It must end in
/resources.
The URL follows this shape:
The base domain is the domain you use to reach Harness. On Harness SaaS this is your cluster domain, for example https://app.harness.io. On Self-Managed Enterprise Edition it is your own Harness hostname.
Add the workspace annotation
The annotation value is a block scalar holding a label and the workspace URL. The label is the name shown for the workspace in the IACM tab, so use something a developer recognizes:
KEEP THE BLOCK SCALAR AND THE LABEL
The | block indicator and the <WORKSPACE_NAME>: label are both part of the annotation format. A bare URL with no label does not match the format the plugin expects. Go to the plugin annotation reference to compare against the canonical example.
Where the entity definition lives determines how you apply the change:
Git-managed entities: Commit the edited
catalog-info.yamlto the tracked branch. The tab appears after the catalog ingests the change on its next sync, not at commit time.Entities created in the catalog UI: Edit the definition in place and save. The tab appears on the next entity refresh.
For a service that spans several environments, name each workspace clearly in the annotation label so developers can tell production from staging at a glance. If you prefer full separation, register one catalog entity per environment, for example payment-service-dev and payment-service-prod.
View infrastructure in the catalog
Once the annotation is ingested, the workspace is visible from the entity page. Follow the interactive walkthrough or the written steps:
The following walkthrough shows how to open an IaCM workspace from an IDP catalog entity.
To open the workspace from the catalog, do the following:
Navigate to Internal Developer Portal > Catalog.
Select the entity that carries the
harness.io/workspace-urlannotation.Select the IACM tab.
The tab is labeled IACM in uppercase in the product, and it contains four groups:
Resources: Every resource the workspace has provisioned, such as compute instances, databases, networks, and storage. Each entry carries its metadata and configuration, and drills down to the resource detail.
Data sources: External data the workspace configuration reads without managing.
Outputs: Values the workspace configuration exports, such as IP addresses, endpoints, and resource identifiers.
Workspace details: The current workspace state, the status of the most recent execution, and a link into IaCM.
Each group shows its own item count. A count of zero means the workspace configuration declares nothing of that kind, which is common for data sources.
What you can do from the IACM tab
The tab is a read-only view onto the workspace. Everything that changes infrastructure happens in the IaCM module.
Review infrastructure context
Use the tab to answer questions about a service's infrastructure without leaving the catalog:
Resources: Confirm what compute, storage, networking, and database resources back the service.
Data sources: Identify the external state and lookups the configuration depends on.
Outputs: Retrieve exported values such as endpoints and connection details.
Workspace state: Check whether the workspace is current, has pending changes, or ended its last run in an error state.
Recent activity: Review the most recent provisioning executions.
Go to Workspace tabs to understand what resources, state, and activity history mean in IaCM, and Workspace statuses to interpret a workspace state.
Open the full workspace
Select View in IaCM or the workspace label to open the workspace in the IaCM module, where you can:
Run plan, apply, and destroy operations.
Review execution logs in detail.
Edit workspace variables, connectors, and configuration.
Review cost estimates produced by the plan.
Inspect state, including historical revisions.
Limitations
Keep the following in mind when you plan a rollout:
The tab is read only. No plan, apply, or destroy operation can be triggered from IDP. Developers who need to change infrastructure must open the workspace in IaCM.
The annotation must point at the
/resourcesview. A URL ending anywhere else in the workspace does not resolve to the resources the tab renders.The tab reflects the last successful apply. A workspace that has never applied, or whose resources were destroyed, renders an empty tab rather than an error.
Viewers need IaCM permissions of their own. The plugin calls Harness with the signed-in user's identity, so a developer without View on the workspace sees an access error even when the annotation is correct.
Troubleshooting
Next steps
Your IaCM workspaces now surface in the IDP service catalog, giving developers infrastructure context on the entity pages they already use. Build on that with the following:
IDP scorecards: Track infrastructure compliance and standards across catalog entities.
IDP workflows: Let developers provision workspaces through self-service actions.
Module registry overview: Share reusable infrastructure modules across services.
IaCM pipeline operations: Automate provisioning and updates for the workspaces you connected.
Last updated
Was this helpful?