OCI Vault, KMS, Logging and security on STACKIT

The migration in seven steps

Answer first: do identity, then keys, then secrets, then logs, and verify each before you retire the source.

1. 01

   1. Inventory the security estate

   List vaults, keys, secrets, log groups, logs, IAM policies and detection settings from your Terraform. The run does this for the resource types it knows and marks the rest as unknown source types.

2. 02

   2. Assess and read the owners

   Run the assessment and open execution/manual/actions.md. It names an owner role per work package and flags the steps that have none.

3. 03

   3. Settle identity first

   An OCI policy has no document-level counterpart on STACKIT. Map people and workloads to STACKIT roles and service accounts before anything depends on them.

4. 04

   4. Create keys and re-encrypt

   Create STACKIT KMS keys. Key material of the source does not move, so data encrypted with it is re-encrypted.

5. 05

   5. Move secrets

   Create secrets in Secrets Manager. Values are moved by an operator, and applications change how they read them.

6. 06

   6. Rebuild logging and audit

   Create a STACKIT Logs instance, point agents at it, and decide how audit streams are routed.

7. 07

   7. Verify, then retire

   Check that each consumer works against the new key, secret and log store, then disable the OCI objects, in that order.

A Vault key and a secret, assessed

A small security estate written for this page and assessed by StackToIT on 4 November 2026. Left: the vault, key and secret as written, lines 16 to 45 of main.tf. Right: the result for the key and the secret, an excerpt of assessment.json with the values as the run wrote them. assessment.json is written as a single line, so the pane shows selected fields of each unit, indented and nested as in the file, with the values unchanged.

resource "oci_kms_vault" "main" {
  compartment_id = var.compartment_id
  display_name   = "platform-vault"
  vault_type     = "DEFAULT"
}

resource "oci_kms_key" "data" {
  compartment_id      = var.compartment_id
  display_name        = "data-key"
  management_endpoint = oci_kms_vault.main.management_endpoint

  key_shape {
    algorithm = "AES"
    length    = 32
  }

  protection_mode = "HSM"
}

resource "oci_vault_secret" "db_password" {
  compartment_id = var.compartment_id
  vault_id       = oci_kms_vault.main.id
  key_id         = oci_kms_key.data.id
  secret_name    = "db-password"

  secret_content {
    content_type = "BASE64"
    content      = base64encode("change-me")
  }
}

[
  {
    "id": "oci_kms_key.data",
    "result": {
      "class": "RECONFIGURE",
      "confidence": "LOW",
      "target": {
        "service": "STACKIT KMS"
      },
      "reason": "A Vault key becomes a STACKIT KMS key. Key material of the source does not move, so data encrypted with it is re-encrypted."
    }
  },
  {
    "id": "oci_vault_secret.db_password",
    "result": {
      "class": "RECONFIGURE",
      "confidence": "LOW",
      "target": {
        "service": "STACKIT Secrets Manager"
      },
      "reason": "A Vault secret becomes a secret in STACKIT Secrets Manager. Values are moved by an operator, and applications change how they read them."
    }
  }
]

• Key material stays behind

  Oracle documents that an HSM-protected key cannot be exported from the HSM, which fits the run: the key is created fresh and the data is re-encrypted. The demo key is an AES key with the protection mode HSM; its settings are inputs to your key design.

• Import is the other path

  STACKIT KMS lets you choose to generate or import a key. Importing is possible; exporting generated keys is not intended. Whether you can use import depends on the key material you hold, which an HSM-protected Oracle key does not give you.

• Secrets are values

  The run speaks of moving values by an operator. Do that from a controlled shell, not from a file that lands in version control; the example secret in the input is a placeholder.

A log group and a log, assessed

A log group with one service log that writes object storage events with 90 days of retention. Lines 47 to 68 of main.tf, and the result for both resources, an excerpt of assessment.json with the values as the run wrote them; the reason text of the log group is summarised below instead of quoted. assessment.json is written as a single line, so the pane shows selected fields of each unit, indented and nested as in the file, with the values unchanged.

resource "oci_logging_log_group" "platform" {
  compartment_id = var.compartment_id
  display_name   = "platform-logs"
}

resource "oci_logging_log" "audit" {
  display_name = "app-service-log"
  log_group_id = oci_logging_log_group.platform.id
  log_type     = "SERVICE"

  configuration {
    source {
      category    = "write"
      resource    = "shop-bucket"
      service     = "objectstorage"
      source_type = "OCISERVICE"
    }
  }

  is_enabled         = true
  retention_duration = 90
}

[
  {
    "id": "oci_logging_log_group.platform",
    "result": {
      "class": "RECONFIGURE",
      "confidence": "LOW",
      "target": {
        "service": "STACKIT Logs"
      }
    }
  },
  {
    "id": "oci_logging_log.audit",
    "result": {
      "class": "MANUAL_REVIEW",
      "confidence": "LOW",
      "reason": "oci_logging_log is not in the knowledge base catalogue; an architect has to decide the target. Nothing of this resource is assessed or drafted (unknown source type)."
    }
  }
]

• Group maps, log does not

  The log group becomes a STACKIT Logs instance; the run's reason says collection agents, queries and the saved views on top of them are rewritten. The log object itself is not in the catalogue of the run and is marked MANUAL_REVIEW.

• The agent changes

  Oracle ingests custom logs with its Unified Monitoring Agent, which is fluentd based. STACKIT Logs accepts Grafana Alloy, the OpenTelemetry Collector, Vector and Fluent Bit, so the agent configuration is rewritten.

• Retention is a setting to confirm

  The demo asks for 90 days. The STACKIT Logs page lists custom retention periods among the features, now also in the region eu02. Set the retention on the instance and confirm it before you rely on it.

The policy, the vault and Cloud Guard

An IAM policy for the operators, the vault container the key and secret live in, and the Cloud Guard configuration. Lines 70 to 84 of main.tf; the run marks all three for an architect. assessment.json is written as a single line, so the pane shows selected fields of each unit, indented and nested as in the file, with the values unchanged.

resource "oci_identity_policy" "vault_use" {
  compartment_id = var.compartment_id
  name           = "vault-use"
  description    = "Let the app group read secrets and use the data key"
  statements = [
    "Allow group app-operators to read secret-family in compartment platform",
    "Allow group app-operators to use keys in compartment platform"
  ]
}

resource "oci_cloud_guard_cloud_guard_configuration" "main" {
  compartment_id   = var.compartment_id
  reporting_region = "eu-frankfurt-1"
  status           = "ENABLED"
}

[
  {
    "id": "oci_identity_policy.vault_use",
    "result": {
      "class": "MANUAL_REVIEW",
      "confidence": "LOW",
      "reason": "OCI policies have no document-level counterpart on STACKIT. Map people and workloads to STACKIT roles and service accounts."
    }
  },
  {
    "id": "oci_kms_vault.main",
    "result": {
      "class": "MANUAL_REVIEW",
      "confidence": "LOW",
      "reason": "oci_kms_vault is not in the knowledge base catalogue; an architect has to decide the target. Nothing of this resource is assessed or drafted (unknown source type)."
    }
  },
  {
    "id": "oci_cloud_guard_cloud_guard_configuration.main",
    "result": {
      "class": "MANUAL_REVIEW",
      "confidence": "LOW",
      "reason": "oci_cloud_guard_cloud_guard_configuration is not in the knowledge base catalogue; an architect has to decide the target. Nothing of this resource is assessed or drafted (unknown source type)."
    }
  }
]

• Policy to roles

  The two statements let a group read secrets and use keys. On STACKIT you express the same intent with roles and service accounts, which your identity architect designs.

• The vault container

  The vault type is not in the catalogue of the run. Its job, holding keys and secrets, is split across KMS key rings and a Secrets Manager instance; decide that split once.

• Cloud Guard has no mapping here

  The Cloud Guard configuration is an unknown source type for the run. Decide which detections you still need and where they run; nothing is proposed for you.

How the security estate maps

Seven resources, seven units: three RECONFIGURE and four MANUAL_REVIEW. All seven carry LOW confidence in this run, and the run writes no STACKIT resource block for them.

Who does what: the owner list

The manual steps file opens with the steps that have no owner role. Five of the seven steps have none in this run, which is the first thing to assign.

## Assign an owner

5 manual steps have no owner role: no role follows from the plan for it, so nobody is named to carry it out. Assign an owner to each; until then the migration is not ready (each shows "Owner assignment required" under Who below).

- the owner table has no role for the category "security" of the unit (2 manual steps): the manual migration of oci_kms_key.data, the manual migration of oci_vault_secret.db_password
- the assessment gives the unit no category, so no owner role follows from it (3 manual steps): the manual migration of oci_cloud_guard_cloud_guard_configuration.main, the manual migration of oci_kms_vault.main, the manual migration of oci_logging_log.audit

• Security has no default owner

  The owner table has no role for the category security, so the key and the secret wait for a name. Give them to the person who owns encryption and secrets.

• Uncategorised units

  The vault, the log and the Cloud Guard configuration carry no category in the assessment, so no role follows from them either. Assign them by hand.

• The policy has an owner

  The IAM policy goes to an Identity Architect, in a work package that a person can start right away.

The order the run proposes

Waves follow dependencies. A unit moves after everything it depends on.

1. 01

   Wave 1

   The Cloud Guard configuration, the IAM policy, the vault and the log group.

2. 02

   Wave 2

   The key and the log, which depend on the vault and the log group.

3. 03

   Wave 3

   The secret, which depends on the vault and the key.

Questions security teams ask

Sources

• Oracle Cloud Infrastructure: Key Management concepts
• Oracle Cloud Infrastructure: Logging overview
• STACKIT: KMS
• STACKIT: Secrets Manager
• STACKIT: Logs
• STACKIT: Telemetry Router