Oracle CloudStatic-verified

A Cloud Guard Target whose Responders Respond

Oracle ships every responder rule in USERACTION mode: a Remediate button appears on each problem and nothing happens until a person clicks it, so a tenancy with hundreds of findings has by default fixed none of them. Sets AUTOACTION per rule and exports the IAM statements each auto-action needs, since one without its policy fails on every execution.

terraformOracle Cloudoci

Compare Security Posture & Findings across clouds →

oci-cloud-guardvizier v1.2.0

Verification

Static-verified

Passed: validated and lint-clean (provider-schema-validated for AWS/Azure/GCP; Terraform-language lint elsewhere).

Conformance

  • Static validation (fmt · validate · tflint)
  • Security scan clean (Checkov)
  • Plan tests (mocked: validation rules · outputs)

Provenance

  • SHA-256 checksum
  • Signature (pending)

Functional

  • Live test pending (no cloud run yet)

Last verified 2026-09-14 · how we verify

Use it from the registry

terraform · opentofu
module "cloud_guard" {
  source  = "www.iac-bazaar.com/iac-bazaar/oci-cloud-guard/oci"
  version = "1.0.0"
}

Needs a registry token from /account/tokens. The module itself is free; the account is what identifies you. Full setup: registry docs.

Inputs & outputs

Create a free account to read this module's contract

The declared contract - every input name, type, default and description, plus every output - is shown to signed-in accounts, not to anonymous visitors.

A free account sees the contract of every module in the catalogue. There is no subscription and nothing to buy - the modules are free to download, and they run under Vizier.

Documentation

oci-cloud-guard

A Cloud Guard target whose responders actually respond. Works with Terraform and OpenTofu (>= 1.6), oci provider >= 8.0, < 9.0.

Every responder rule starts in "ask me first" mode. Cloud Guard has two halves: detectors find the public bucket or the stopped audit trail, and responders can fix it. Oracle's managed responder recipe ships every rule in USERACTION - a Remediate button appears on the problem and nothing happens until a person clicks it. A tenancy with Cloud Guard on, the managed recipes attached and hundreds of problems listed has, by default, fixed none of them, and the dashboard cannot tell you that. AUTOACTION is set per rule per target; this module takes the list of rules that should act, and refuses a target with none of them without accept_advisory_only.

AUTOACTION also needs a policy. Cloud Guard fixes a bucket by calling Object Storage as itself. The IAM statements each rule needs are reported by the API and exported here as policies_required, so a test can check them against what the tenancy actually grants - an auto-action without its policy fails on every execution.

A target is a compartment and everything beneath it. inherited_by_compartments is the real scope.

The tenancy-level switch is separate and its reporting region cannot be changed later. manage_tenancy_configuration = true sets it from the first target; leave it false for every later one.

Verification

Static validation runs tofu fmt, init, validate, tflint and checkov. This module has not yet had a live test, so it is published as statically validated with its live test pending and does not carry the live-tested mark.

Usage code & full reference need an account

The complete copy-paste usage, the full input/output reference, and operational notes are free with an account - shown here and bundled in the download. Sign in and this section fills in.

  • Usage

Related modules

Static validatedLive test pending

oci-security-zone

The opposite of every other guardrail here: a security zone does not detect or report, it REFUSES - the API call fails. There is no dry-run mode. So the risk inverts too: applied to a compartment that already holds non-compliant resources, the team that owns them discovers they can no longer change them.

View module
Static validatedLive test pending

oci-network-firewall

An INSPECT rule hands the flow to the threat engine, and inspection decides what happens next: INTRUSION_PREVENTION drops the session, INTRUSION_DETECTION logs it and forwards it, and the rule reads INSPECT either way. Every inspect rule is prevention unless detection is accepted by name; policy and appliance are both created, and the address the route tables must point at is an output.

View module
Static validatedLive test pending

oci-waf

CHECK is the action that evaluates the rule, logs the match and lets the request through - the console shows the protection rules and every matched attack reached the backend. BLOCK by default, DETECT only by name. The policy and the firewall binding it to a load balancer are separate resources; both are created, and a policy alone has to be asked for.

View module
Static validatedLive test pending

oci-bastion

Zero-footprint managed bastion with session-managed SSH/port-forward access to private subnets - replaces jump hosts.

View module
Static validatedLive test pending

oci-vulnerability-scanning

scan_level = NONE is legal for both the agent scan and the port scan, so a recipe with both at NONE runs on schedule, updates its last-run time, and finds nothing because it looked for nothing. A recipe is not a target either: one with no target scans no instance. Refuses a recipe that scans for nothing and always creates the target with it.

View module
Static validatedLive test pending

azure-defender-for-cloud

A subscription with no Defender plan still has a full Defender for Cloud page: a Secure Score, hundreds of recommendations, a compliance dashboard - and not one threat detection, because those come from the paid plans, each Off until somebody turns it on. Sets Standard per resource type, always creates the security contact, and defaults alert notifications on.

View module