JFrog Xray Terraform Provider
repository·main·Indexed 41 days ago
https://github.com/jfrog/terraform-provider-xrayTerraform 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.
What's inside JFrog Xray Terraform Provider
- The JFrog Xray provider allows you to manage and interact with resources supported by JFrog Xray via Terraform. Note that Xray is a component of JFrog Artifactory and cannot be used as a standalone product. To use the provider, you must configure it with valid credentials. For detailed information on the underlying APIs, refer to the Xray REST API documentation.
Manage Xray Watches with xray_watch
mainThe
xray_watchresource 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, andgitRepository. - 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"] }- Monitoring various resource types:
Configure Xray security policy rules and criteria
mainAn
xray_security_policyis composed of one or moreruleblocks. Each rule defines specificcriteriathat trigger a set ofactions.Common Criteria Types
- Severity: Use
min_severity(e.g.,"High") andfix_version_dependant(boolean) within acriteriablock. - CVSS Score: Use the
cvss_rangeblock withfromandto(floats) to define a score range. - SAST: Use the
sastblock withmin_severityto define Static Application Security Testing thresholds. - Malicious Packages: Set
malicious_package = truewithin thecriteriablock 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 } } }- Severity: Use
Xray license requirements
mainTo 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/How the Terraform provider execution model works
mainTo debug the provider effectively, it is important to understand its lifecycle:
- RPC Server Model: Every Terraform provider acts as a mini RPC server. When Terraform runs, it starts the provider as a separate, new process.
- Ephemeral Lifecycle: The provider process is ephemeral; it typically only lives for the duration of the specific Terraform command being executed.
- 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.
Set granular retention and scanning with paths_config
mainThe
paths_configblock 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 usepatternblocks, you must define anall_other_artifactsblock 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.
Use Contextual Analysis and Runtime filters in reports
mainFor Xray versions 3.130.0 or higher, you can apply advanced filtering within the
filtersblock:Contextual Analysis (CA) Filter
Use the
ca_filterblock to filter by the status of the contextual analysis. Supportedallowed_ca_statusesinclude:applicablenot_applicableundeterminednot_scannedtechnology_unsupportedupgrade_requiredrescan_requirednot_covered
Runtime Filter
Use the
runtime_filterblock 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" } }Assign policies to an Xray Watch
mainUse the
assigned_policyblock to attach Xray policies to a watch. You can assign multiple policies of different types to a single watch.Supported
typevalues forassigned_policy:securitylicenseoperational_risk
The
namefield must match the name of an existing Xray policy (e.g., from anxray_security_policyresource).assigned_policy { name = xray_security_policy.min_severity.name type = "security" } assigned_policy { name = xray_license_policy.banned_licenses.name type = "license" }Define report scope using `resources`
mainThe
resourcesblock defines the scope of the report. You can target different Xray entities:- Repositories: Use
repositoryblocks. You can specifyname,include_path_patterns, andexclude_path_patterns. - Builds: Use
buildsblocks. Specifynamesandnumber_of_latest_versions. - Projects: Use
projectsblocks. Specifykeysandnumber_of_latest_versions. - Release Bundles: Use
release_bundlesblocks. Specifynamesandnumber_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 } }- Repositories: Use
Configure watch_resource types and filters
mainThe
watch_resourceblock defines what Xray is monitoring. You can define multiplewatch_resourceblocks within a singlexray_watchto monitor different entities.Supported Resource Types
all-repos: Monitors all repositories.repository: Monitors specific repositories. Requiresbin_mgr_id,name, andrepo_type(localorremote).all-builds: Monitors all builds. Requiresbin_mgr_id.build: Monitors specific builds. Requiresbin_mgr_idandname.all-projects: Monitors all projects. Requiresbin_mgr_id.project: Monitors specific projects. Requiresname.gitRepository: Monitors Git repositories. Requiresbin_mgr_idandname.
Filtering Options within watch_resource
Depending on the resource type, you can apply various filters:
filter: Usestype(e.g.,regex,mime-type) andvalueto filter artifacts.ant_filter: Usesinclude_patternsandexclude_patterns(Ant-style patterns) for builds or projects.path_ant_filter: Usesinclude_patternsandexclude_patternsfor file paths within a repository.kv_filter: Usestype(e.g.,property),key, andvalueto 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" } }How the Terraform provider architecture affects debugging
mainThe 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:
- Memory Isolation: The provider code resides in the memory space of an entirely different process than the Terraform CLI.
- 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.
Configure the JFrog Xray Provider
mainTo use the Xray provider, declare it in your
terraformblock and configure theprovider "xray"block with your Xray instance URL and authentication credentials. You can provide credentials via theaccess_tokenargument 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 tofalse.
Environment Variables:
JFROG_URLorXRAY_URL: Set the Xray URL.XRAY_ACCESS_TOKENorJFROG_ACCESS_TOKEN: Set the access token.SKIP_XRAY_VERSION_CHECK: Set totrueto 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 }