JFrog Xray Terraform Provider

repository·main·Indexed 41 days ago

https://github.com/jfrog/terraform-provider-xray

Terraform provider for JFrog Xray that allows users to manage Xray resources via Terraform configuration. It supports managing security and license policies, creating watches to apply policies to resources, and utilizing data sources like xray_artifacts_scan and xray_curation_condition. Requires a supported JFrog Xray license (Pro Team or Pro X) and Terraform 0.13 or higher.

Tokens
36.8K
Snippets
88
Records
150
Agent score
98%

What's inside JFrog Xray Terraform Provider

  1. Manage Xray Watches with xray_watch

    main

    The xray_watch resource allows you to create and manage Xray Watches. A Watch monitors specific resources (like repositories, builds, or projects) and applies security, license, or operational risk policies to them. When a policy violation is detected, notifications can be sent to specified recipients.

    Key capabilities include:

    • Monitoring various resource types: all-repos, repository, all-builds, build, all-projects, project, and gitRepository.
    • Applying multiple policies of different types (security, license, operational_risk) to a single watch.
    • Filtering resources using regex, mime-type, Ant patterns, or key-value properties.
    • Specifying notification recipients via watch_recipients.
    resource "xray_watch" "example" {
      name        = "example-watch"
      description = "A watch for a specific repository"
      active      = true
      project_key = "my-project"
    
      watch_resource {
        type       = "repository"
        bin_mgr_id = "default"
        name       = "my-repo"
        repo_type  = "local"
      }
    
      assigned_policy {
        name = "my-security-policy"
        type = "security"
      }
    
      watch_recipients = ["admin@example.com"]
    }
  2. Configure Xray security policy rules and criteria

    main

    An xray_security_policy is composed of one or more rule blocks. Each rule defines specific criteria that trigger a set of actions.

    Common Criteria Types

    • Severity: Use min_severity (e.g., "High") and fix_version_dependant (boolean) within a criteria block.
    • CVSS Score: Use the cvss_range block with from and to (floats) to define a score range.
    • SAST: Use the sast block with min_severity to define Static Application Security Testing thresholds.
    • Malicious Packages: Set malicious_package = true within the criteria block to target malicious software.

    Example: CVSS Range Rule

    resource "xray_security_policy" "cvss_score" {
      name        = "test-security-policy-cvss"
      description = "Security policy description"
      type        = "security"
      project_key = "testproj"
    
      rule {
        name     = "rule-name-cvss"
        priority = 1
    
        criteria {
          cvss_range {
            from = 1.5
            to   = 5.3
          }
        }
    
        actions {
          mails = ["test@email.com"]
          fail_build = true
        }
      }
    }
    resource "xray_security_policy" "cvss_score" {
      name        = "test-security-policy-cvss"
      description = "Security policy description"
      type        = "security"
      project_key = "testproj"
    
      rule {
        name     = "rule-name-cvss"
        priority = 1
    
        criteria {
          cvss_range {
            from = 1.5
            to   = 5.3
          }
        }
    
        actions {
          mails = ["test@email.com"]
          fail_build = true
        }
      }
    }
  3. Xray license requirements

    main

    To use this provider, Xray must be enabled in your Artifactory installation. Supported licenses include:

    • Pro Team (Public Marketplace version or SaaS)
    • Pro X (Self-hosted)

    You can verify your current license by accessing the following endpoint on your Artifactory host: ${host}/artifactory/api/system/licenses/

  4. How the Terraform provider execution model works

    main

    To debug the provider effectively, it is important to understand its lifecycle:

    1. RPC Server Model: Every Terraform provider acts as a mini RPC server. When Terraform runs, it starts the provider as a separate, new process.
    2. Ephemeral Lifecycle: The provider process is ephemeral; it typically only lives for the duration of the specific Terraform command being executed.
    3. Memory Isolation: The provider runs in its own memory space, separate from the main Terraform process. This is why standard debuggers cannot simply 'load' the provider into the Terraform process memory; you must attach to the specific provider PID.
  5. Set granular retention and scanning with paths_config

    main

    The paths_config block enables fine-grained control over retention periods and scanning for specific paths within a repository.

    Pattern-based configuration (pattern):

    • include (String, Required): The path pattern to include.
    • exclude (String): The path pattern to exclude.
    • index_new_artifacts (Boolean): If true, Xray scans newly added artifacts in the path (existing artifacts are not scanned).
    • retention_in_days (Number): The retention period for artifacts in this specific path.

    Fallback configuration (all_other_artifacts): If you use pattern blocks, you must define an all_other_artifacts block to set the retention period for any artifacts that do not match your defined patterns.

    • index_new_artifacts (Boolean): Whether to scan newly added artifacts in the fallback path.
    • retention_in_days (Number): The retention period for all other artifacts.
  6. Use Contextual Analysis and Runtime filters in reports

    main

    For Xray versions 3.130.0 or higher, you can apply advanced filtering within the filters block:

    Contextual Analysis (CA) Filter

    Use the ca_filter block to filter by the status of the contextual analysis. Supported allowed_ca_statuses include:

    • applicable
    • not_applicable
    • undetermined
    • not_scanned
    • technology_unsupported
    • upgrade_required
    • rescan_required
    • not_covered

    Runtime Filter

    Use the runtime_filter block to filter based on a time period.

    • time_period: A duration string (e.g., "7 days", "30 days", "24 hours").
    filters {
      # Contextual Analysis Filter (requires Xray 3.130.0 or higher)
      ca_filter {
        allowed_ca_statuses = ["applicable", "not_applicable"]
      }
    
      # Runtime Filter (requires Xray 3.130.0 or higher)
      runtime_filter {
        time_period = "7 days"
      }
    }
  7. Assign policies to an Xray Watch

    main

    Use the assigned_policy block to attach Xray policies to a watch. You can assign multiple policies of different types to a single watch.

    Supported type values for assigned_policy:

    • security
    • license
    • operational_risk

    The name field must match the name of an existing Xray policy (e.g., from an xray_security_policy resource).

    assigned_policy {
      name = xray_security_policy.min_severity.name
      type = "security"
    }
    
    assigned_policy {
      name = xray_license_policy.banned_licenses.name
      type = "license"
    }
  8. Define report scope using `resources`

    main

    The resources block defines the scope of the report. You can target different Xray entities:

    • Repositories: Use repository blocks. You can specify name, include_path_patterns, and exclude_path_patterns.
    • Builds: Use builds blocks. Specify names and number_of_latest_versions.
    • Projects: Use projects blocks. Specify keys and number_of_latest_versions.
    • Release Bundles: Use release_bundles blocks. Specify names and number_of_latest_versions.
    resources {
      repository {
        name                  = "docker-local"
        include_path_patterns = ["folder1/path/*", "folder2/path*"]
        exclude_path_patterns = ["folder1/path2/*", "folder2/path2*"]
      }
    }
    
    # Or for builds
    resources {
      builds {
        names                     = ["build-1", "build-2"]
        number_of_latest_versions = 5
      }
    }
  9. Configure watch_resource types and filters

    main

    The watch_resource block defines what Xray is monitoring. You can define multiple watch_resource blocks within a single xray_watch to monitor different entities.

    Supported Resource Types

    • all-repos: Monitors all repositories.
    • repository: Monitors specific repositories. Requires bin_mgr_id, name, and repo_type (local or remote).
    • all-builds: Monitors all builds. Requires bin_mgr_id.
    • build: Monitors specific builds. Requires bin_mgr_id and name.
    • all-projects: Monitors all projects. Requires bin_mgr_id.
    • project: Monitors specific projects. Requires name.
    • gitRepository: Monitors Git repositories. Requires bin_mgr_id and name.

    Filtering Options within watch_resource

    Depending on the resource type, you can apply various filters:

    • filter: Uses type (e.g., regex, mime-type) and value to filter artifacts.
    • ant_filter: Uses include_patterns and exclude_patterns (Ant-style patterns) for builds or projects.
    • path_ant_filter: Uses include_patterns and exclude_patterns for file paths within a repository.
    • kv_filter: Uses type (e.g., property), key, and value to filter based on artifact properties.
    resource "xray_watch" "repository-with-filters" {
      name        = "repo-watch"
      active      = true
      project_key = "testproj"
    
      # Example: Repository with mime-type filter
      watch_resource {
        type       = "repository"
        bin_mgr_id = "default"
        name       = "my-repo"
        repo_type  = "remote"
    
        filter {
          type  = "mime-type"
          value = "application/json"
        }
      }
    
      # Example: Repository with path Ant filter
      watch_resource {
        type       = "repository"
        bin_mgr_id = "default"
        name       = "my-repo-2"
        repo_type  = "local"
    
        path_ant_filter {
          exclude_patterns = ["**/*.md"]
          include_patterns = ["**/*.js"]
        }
      }
    
      # Example: Repository with property (KV) filter
      watch_resource {
        type       = "repository"
        bin_mgr_id = "default"
        name       = "my-repo-3"
        repo_type  = "local"
    
        kv_filter {
          type  = "property"
          key   = "artifact-property-name"
          value = "artifact-property-value"
        }
      }
    
      assigned_policy {
        name = "my-policy"
        type = "security"
      }
    }
  10. How the Terraform provider architecture affects debugging

    main

    The Terraform provider operates as a standalone mini RPC server. When you run Terraform, it starts the provider as a separate process and communicates with it via an RPC channel.

    This architecture creates two main challenges for developers:

    1. Memory Isolation: The provider code resides in the memory space of an entirely different process than the Terraform CLI.
    2. Ephemeral Lifecycles: The provider process is often short-lived, potentially existing for only a few seconds, which makes it difficult to attach a debugger before the process terminates.
  11. Configure the JFrog Xray Provider

    main

    To use the Xray provider, declare it in your terraform block and configure the provider "xray" block with your Xray instance URL and authentication credentials. You can provide credentials via the access_token argument or through environment variables.

    Provider Configuration Options:

    • url: The URL of your Xray instance (e.g., artifactory.site.com/xray).
    • access_token: Your Xray access token.
    • skip_xray_version_check: (Optional) Boolean to skip the Xray version check. Defaults to false.

    Environment Variables:

    • JFROG_URL or XRAY_URL: Set the Xray URL.
    • XRAY_ACCESS_TOKEN or JFROG_ACCESS_TOKEN: Set the access token.
    • SKIP_XRAY_VERSION_CHECK: Set to true to skip the version check.
    terraform {
      required_providers {
        xray = {
          source  = "jfrog/xray"
          version = "3.1.1"
        }
      }
    }
    
    provider "xray" {
      url          = "artifactory.site.com/xray"
      access_token = "abc..xy"
      
      // optional: Skip xray version check, default is false.
      // skip_xray_version_check = true
    }