> For the complete documentation index, see [llms.txt](https://experience-digital-transform.gitbook.io/experience-digital-transformation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://experience-digital-transform.gitbook.io/experience-digital-transformation/information-mediator/install-the-information-mediator-security-server.md).

# Install the Information Mediator Security Server

This page explains how to deploy a GovStack Information Mediator Security Server using the automation in the `bb-im-connector` repository. The repository implements the Information Mediator Security Server on X-Road and deploys it to Kubernetes with Helm.

## What the automation installs

The installation workflow deploys an X-Road Security Server into the Kubernetes namespace configured by the repository. In the repository defaults, that namespace is `im-ns`.

The Helm chart uses the NIIS X-Road Security Server sidecar image by default. The checked-in chart currently specifies X-Road version `7.6.2` and defines persistent storage for configuration, library data, and database data.

The installation role first checks that it is running on the intended cluster. Specifically, it verifies that the `xroad-im` namespace does **not** exist; if that namespace is present, the role stops rather than installing the Security Server on the wrong cluster.

## Prerequisites

Before running the installation, the repository README requires:

* Ansible 2.9 or later
* `kubectl` configured with access to the Kubernetes cluster where the Security Server will run
* Helm 3.0 or later
* the Python Kubernetes library (`pip install kubernetes`)
* network access to the external Central Server, test CA endpoints, and the target Security Server cluster

The repository also expects its Ansible inventory and group variables to be configured for the target environment.

## Configure the deployment

The repository separates general defaults from deployment-specific configuration and secrets.

The checked-in defaults define values such as:

* the Information Mediator namespace;
* Central Server and Management Security Server endpoints;
* test CA, OCSP, ACME, and TSA endpoints;
* the Security Server hostname and chart name;
* certificate subject information;
* Helm timeout and image settings.

The repository README and `GETTING_STARTED.md` instruct users to configure organization-specific values in `group_vars/all/config.yml` and to create `group_vars/all/secrets.yml` from `group_vars/all/secrets.yml.example`.

{% hint style="warning" %}
**Source note:** In the repository snapshot reviewed for this page, `group_vars/all/config.yml` is referenced by the documentation but is not present in the checked-in repository. Do not invent its contents. Use `group_vars/CONFIG_DOCUMENTATION.md` as the source for the intended configuration schema and create the deployment-specific file accordingly.
{% endhint %}

### Organization and member identity

The configuration guide defines the organization through values such as:

```yaml
bb_member:
  name: "My Organization"
  class: "GOV"
  code: "123456"
  server:
    code: "SS-001"
```

The broader configuration schema also defines:

* the GovStack domain and instance;
* the Building Block cluster/domain identity;
* member class and member code;
* Security Server code;
* certificate country and organization fields;
* one or more DSS/subsystem definitions;
* services exposed by each DSS/subsystem;
* access rights for each service.

### Secrets

Create the secrets file from the supplied example:

```bash
cp group_vars/all/secrets.yml.example group_vars/all/secrets.yml
```

Then populate the required passwords/secrets before running the playbooks.

## Run the installation

The top-level installation playbook is:

```bash
ansible-playbook installation.yml
```

That playbook invokes the repository's `installation` role.

The role:

1. verifies that the target cluster is appropriate for the Security Server deployment;
2. sets the Helm release name based on the configured Security Server instance;
3. installs or upgrades the Security Server from the repository's local Helm chart;
4. creates the namespace if necessary;
5. waits for the Security Server pod to reach the Running state;
6. reports the resulting installation status.

The Helm deployment is designed to be repeatable: the repository uses an install-or-upgrade workflow rather than assuming a one-time deployment.

## What happens next

Installation only deploys the Security Server. It does not complete the trust and registration workflow.

After installation, continue with the pre-approval configuration step:

```bash
ansible-playbook configure-step1.yml
```

That second phase initializes the Security Server, imports the configuration anchor, prepares signing and authentication certificates, and configures the member, subsystems, and services before the approval-dependent final step.

## Source basis

This page is based on the repository's:

* `README.md`
* `GETTING_STARTED.md`
* `installation.yml`
* `roles/installation/tasks/main.yml`
* `group_vars/all/all.yml`
* `group_vars/CONFIG_DOCUMENTATION.md`
* `helm-chart/Chart.yaml`
* `helm-chart/values.yaml`


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://experience-digital-transform.gitbook.io/experience-digital-transformation/information-mediator/install-the-information-mediator-security-server.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.