GitLab CI\/CD has become the backbone of modern DevSecOps, offering an integrated platform where code, pipelines, security scanning, and deployments converge in a single interface. But that deep integration is a double-edged sword: a misconfigured pipeline can expose secrets, allow unauthorized deployments, or give attackers a foothold in your infrastructure.<\/p>\n\n
This definitive guide covers every security-relevant surface of GitLab CI\/CD \u2014 from protected variables and runner scoping to OIDC federation and merge request pipeline safety. Whether you are hardening an existing GitLab installation or building a greenfield DevSecOps practice, this post gives you the knowledge and actionable checklists you need.<\/p>\n\n
GitLab positions itself as the “One DevOps Platform,” and for good reason. Source control, issue tracking, CI\/CD, container registry, package registry, security scanning, and deployment management all live under one roof. That consolidation simplifies tooling \u2014 but it also concentrates risk. A single compromised pipeline job can potentially read source code, steal credentials, push malicious images, and trigger production deployments.<\/p>\n\n
Recent supply-chain attacks have demonstrated that CI\/CD pipelines are high-value targets. Attackers who gain the ability to inject steps into a pipeline \u2014 whether through a poisoned dependency, a compromised shared runner, or a malicious merge request \u2014 can exfiltrate secrets, tamper with build artifacts, or move laterally into cloud environments. GitLab provides a rich set of controls to prevent these outcomes, but only if you understand and enable them.<\/p>\n\n
Before diving into individual controls, it helps to understand the four pillars of the GitLab CI security model:<\/p>\n\n
CI_JOB_TOKEN<\/code>, OIDC id_tokens<\/code>) that authenticate jobs to other services. Scoping limits their blast radius.<\/li>\n<\/ol>\n\nEvery hardening measure in this guide maps back to one or more of these pillars. Master all four, and you will have a defense-in-depth posture that can withstand both insider mistakes and external attacks.<\/p>\n\n
Protected and Masked Variables<\/h2>\n\n
CI\/CD variables are the primary mechanism for injecting secrets \u2014 API keys, cloud credentials, database passwords \u2014 into pipeline jobs. GitLab offers two orthogonal safeguards: protection<\/strong> and masking<\/strong>.<\/p>\n\nProtected Variables<\/h3>\n\n
When a variable is marked as protected<\/em>, GitLab only exposes it to jobs running on protected branches<\/strong> or protected tags<\/strong>. This is a critical control: it means a developer who opens a merge request from a feature branch cannot write a pipeline step that echoes your production AWS credentials. The variable simply does not exist in the job’s environment for unprotected refs.<\/p>\n\nBest practices for protected variables:<\/strong><\/p>\n\n\n- Mark every production secret as protected. There is no valid reason for a feature-branch job to access production credentials.<\/li>\n
- Limit who can push to or merge into protected branches (Maintainer role or above). This creates a human gate before secrets are accessible.<\/li>\n
- Use environment-scoped variables when the same secret name differs between staging and production. GitLab will inject the correct value based on the
environment:<\/code> keyword in the job definition.<\/li>\n- Rotate protected variables regularly. Even protected variables can leak through misconfigured logging or compromised runners.<\/li>\n<\/ul>\n\n
Masked Variables<\/h3>\n\n
Masking prevents a variable’s value from appearing in job logs. GitLab replaces any occurrence of the value with [MASKED]<\/code>. Masking is a safety net, not a security boundary \u2014 it protects against accidental exposure (e.g., a verbose curl<\/code> command logging headers) but does not prevent a malicious job step from Base64-encoding the value or writing it to an artifact.<\/p>\n\nCombine protection and masking.<\/strong> A variable that is protected and<\/em> masked gives you the strongest built-in defense: limited branch scope plus log-level redaction.<\/p>\n\nRunner Types and Scoping<\/h2>\n\n
Runners are where your code actually executes. Understanding runner types and their security implications is essential for a hardened GitLab CI environment.<\/p>\n\n
Shared, Group, and Project Runners<\/h3>\n\n
GitLab supports three scopes for runners:<\/p>\n\n
\n- Shared runners<\/strong> \u2014 available to all projects in the instance. Convenient but highest risk: a malicious project can potentially leave artifacts, caches, or processes that affect the next job from an unrelated project.<\/li>\n
- Group runners<\/strong> \u2014 available to all projects within a specific group. A reasonable middle ground that limits cross-project exposure while reducing runner management overhead.<\/li>\n
- Project runners<\/strong> \u2014 dedicated to a single project. Maximum isolation, but higher operational cost. Recommended for high-security repositories that handle production secrets or sensitive customer data.<\/li>\n<\/ul>\n\n
Protected Runners<\/h3>\n\n
Any runner can be marked as protected<\/strong>. A protected runner only picks up jobs from protected branches or protected tags. This pairs naturally with protected variables: your production deployment runner only executes on main<\/code>, and only jobs on main<\/code> have access to production secrets.<\/p>\n\nRunner hardening checklist:<\/strong><\/p>\n\n\n- Use ephemeral runners (auto-scaled, destroyed after each job) to eliminate data persistence between jobs.<\/li>\n
- Run Docker-in-Docker with
--privileged<\/code> only when absolutely necessary, and isolate those runners in a dedicated security group.<\/li>\n- Disable the shell executor on shared runners. Use Docker or Kubernetes executors with restrictive security contexts.<\/li>\n
- Tag production deployment runners and lock them to specific projects and protected branches.<\/li>\n
- Audit runner registration tokens \u2014 rotate them regularly and revoke any leaked tokens immediately.<\/li>\n<\/ul>\n\n
Protected Environments and Deployment Approvals<\/h2>\n\n
GitLab environments represent deployment targets such as staging<\/code>, production<\/code>, or canary<\/code>. Protecting an environment adds an authorization layer that goes beyond branch protection.<\/p>\n\nHow Protected Environments Work<\/h3>\n\n
When you protect an environment, you specify which users or groups are allowed to deploy to it. Even if a pipeline runs on a protected branch, the deployment job will not execute unless the triggering user has the required permission. This creates a separation of duties: developers can merge code, but only designated deployers can push it to production.<\/p>\n\n
Deployment Approvals (Premium\/Ultimate)<\/h3>\n\n
GitLab Premium and Ultimate tiers offer deployment approvals<\/strong> \u2014 a mechanism that pauses a deployment job and waits for one or more designated approvers to give the green light. This is invaluable for regulated environments where change-management processes require human sign-off before production changes go live.<\/p>\n\nConfiguration tips:<\/strong><\/p>\n\n\n- Require at least two approvers for production deployments to prevent single-person compromise.<\/li>\n
- Set approval rules at the group level so they apply consistently across all projects within a business unit.<\/li>\n
- Combine deployment approvals with protected runners and protected variables for a layered defense.<\/li>\n
- Use the
environment: deployment_tier<\/code> keyword to classify environments (production, staging, testing, development) and apply appropriate policies to each tier.<\/li>\n<\/ul>\n\nCI_JOB_TOKEN Scoping<\/h2>\n\n
Every GitLab CI job receives an automatically generated CI_JOB_TOKEN<\/code> \u2014 a short-lived credential that authenticates the job to the GitLab API, container registry, and package registry. By default, this token can access resources across projects, which creates a lateral-movement risk.<\/p>\n\nLimiting CI_JOB_TOKEN Access<\/h3>\n\n
GitLab 15.9+ introduced CI\/CD job token scope<\/strong> controls. You can now configure an allowlist of projects that a given project’s CI_JOB_TOKEN<\/code> can access. This is a must-enable setting for any security-conscious organization.<\/p>\n\nSteps to harden CI_JOB_TOKEN:<\/strong><\/p>\n\n\n- Navigate to Settings > CI\/CD > Token Access<\/strong> in your project.<\/li>\n
- Enable Limit CI_JOB_TOKEN access<\/strong> (this restricts the token to the current project by default).<\/li>\n
- Add only the specific projects that this project’s jobs legitimately need to access.<\/li>\n
- Review the allowlist quarterly and remove stale entries.<\/li>\n<\/ol>\n\n
With scoped tokens, even if an attacker compromises a pipeline job, the blast radius is limited to the explicitly allowed projects rather than the entire GitLab instance.<\/p>\n\n
OIDC Federation with id_tokens<\/h2>\n\n
Hard-coded cloud credentials in CI variables are a persistent security risk. GitLab’s OIDC (OpenID Connect)<\/strong> support eliminates this risk entirely by allowing pipeline jobs to authenticate to cloud providers using short-lived, cryptographically signed tokens.<\/p>\n\nHow It Works<\/h3>\n\n
When you define an id_tokens<\/code> block in your .gitlab-ci.yml<\/code>, GitLab generates a signed JWT for each job. The JWT contains claims about the job \u2014 project path, ref name, environment, pipeline source \u2014 that the cloud provider can evaluate against its trust policy.<\/p>\n\ndeploy_production:\n id_tokens:\n GITLAB_OIDC_TOKEN:\n aud: https:\/\/aws.example.com\n script:\n - |\n export AWS_WEB_IDENTITY_TOKEN_FILE=$(mktemp)\n echo \"$GITLAB_OIDC_TOKEN\" > $AWS_WEB_IDENTITY_TOKEN_FILE\n aws sts assume-role-with-web-identity \\\n --role-arn arn:aws:iam::123456789012:role\/gitlab-deploy \\\n --web-identity-token file:\/\/$AWS_WEB_IDENTITY_TOKEN_FILE\n<\/code><\/pre>\n\nOn the cloud side (AWS, GCP, Azure), you configure a trust policy that only accepts tokens from specific projects, branches, and environments. This means:<\/p>\n\n
\n- No static credentials<\/strong> to rotate or leak.<\/li>\n
- Fine-grained access<\/strong> \u2014 a token from a feature branch can be rejected by the cloud provider, even if the pipeline is otherwise valid.<\/li>\n
- Auditability<\/strong> \u2014 every authentication event is logged with the full JWT claims.<\/li>\n<\/ul>\n\n
For a deep dive into OIDC federation patterns across AWS, GCP, and Azure, see our dedicated guide: Short-Lived Credentials & Workload Identity Federation for CI\/CD<\/a>.<\/p>\n\nMerge Request Pipeline Security<\/h2>\n\n
Merge requests are the most common vector for injecting malicious code into pipelines. An external contributor (or a compromised account) can submit a merge request that modifies .gitlab-ci.yml<\/code> to exfiltrate secrets or establish persistence.<\/p>\n\nKey Protections<\/h3>\n\n\n- Use
rules: - if: $CI_PIPELINE_SOURCE == 'merge_request_event'<\/code><\/strong> to create dedicated MR pipelines that run with reduced privileges. MR pipelines from forks do not have access to protected variables by default.<\/li>\n- Require pipeline success before merging.<\/strong> This ensures that security scans (SAST, dependency scanning, secret detection) run on every MR.<\/li>\n
- Limit
include:<\/code> to trusted sources.<\/strong> Malicious MRs can add include: remote:<\/code> directives that pull in attacker-controlled YAML. Use an allowlist of permitted include domains or pin to specific refs.<\/li>\n- Enable “Pipelines must succeed” and “All threads must be resolved”<\/strong> in your project’s merge request settings.<\/li>\n
- Review
.gitlab-ci.yml<\/code> changes carefully.<\/strong> Any MR that modifies pipeline configuration should require approval from a security-aware reviewer.<\/li>\n<\/ul>\n\nFork Pipeline Restrictions<\/h3>\n\n
For public or open-source projects, fork pipelines present additional risks. GitLab allows you to:<\/p>\n\n
\n- Run fork pipelines in a restricted mode without access to project CI variables.<\/li>\n
- Require manual approval before running pipelines from forks (available in Premium\/Ultimate).<\/li>\n
- Use separate, unprivileged runners for fork pipelines.<\/li>\n<\/ul>\n\n
Secret Detection with Built-in SAST Templates<\/h2>\n\n
GitLab ships with built-in SAST (Static Application Security Testing) templates that include secret detection. Enabling them is straightforward:<\/p>\n\n
include:\n - template: Jobs\/Secret-Detection.gitlab-ci.yml\n - template: Jobs\/SAST.gitlab-ci.yml\n<\/code><\/pre>\n\nThe secret detection scanner uses pattern matching and entropy analysis to identify leaked credentials, API keys, private keys, and tokens in your codebase. Results appear in the merge request security widget, making it easy for reviewers to catch leaks before they reach the default branch.<\/p>\n\n
Maximizing secret detection effectiveness:<\/strong><\/p>\n\n\n- Enable pipeline-level secret detection<\/strong> (not just historical scanning) so every commit is checked.<\/li>\n
- Configure push rules<\/strong> to reject commits containing known secret patterns (e.g.,
AKIA<\/code> for AWS access keys).<\/li>\n- Integrate with GitLab’s vulnerability management<\/strong> to track, triage, and resolve detected secrets.<\/li>\n
- Add custom patterns for organization-specific secret formats (internal API keys, service account tokens).<\/li>\n
- Run secret detection on both the source branch and the merge result to catch secrets introduced by merge conflicts.<\/li>\n<\/ul>\n\n
Secure Deployment Workflows<\/h2>\n\n
Getting code from a pipeline to a production environment securely requires more than just running kubectl apply<\/code>. GitLab supports several deployment strategies that balance speed with safety.<\/p>\n\nManual Gates<\/h3>\n\n
Use the when: manual<\/code> keyword to create explicit approval points in your pipeline. A common pattern is to auto-deploy to staging but require a manual click for production. Combined with protected environments and deployment approvals, this creates a robust change-management workflow.<\/p>\n\ndeploy_production:\n stage: deploy\n environment:\n name: production\n deployment_tier: production\n when: manual\n only:\n - main\n<\/code><\/pre>\n\nCanary Deployments<\/h3>\n\n
GitLab integrates with Kubernetes to support canary deployments natively. By deploying to a small percentage of pods first and monitoring error rates, you can catch issues before they affect all users. This is a security control as well as a reliability one \u2014 a compromised build that reaches canary can be caught and rolled back before it goes wide.<\/p>\n\n
GitOps with the GitLab Agent for Kubernetes<\/h3>\n\n
The GitLab Agent for Kubernetes (formerly known as KAS) enables a pull-based GitOps model. Instead of granting your CI pipeline direct access to the Kubernetes API, the agent running inside the cluster pulls desired state from a Git repository. This eliminates the need for long-lived kubeconfig credentials in CI variables and reduces the attack surface significantly.<\/p>\n\n
Deployment security best practices:<\/strong><\/p>\n\n\n- Never store kubeconfig or cloud credentials as unprotected CI variables. Use OIDC federation or the GitLab Agent.<\/li>\n
- Implement rollback automation \u2014 if health checks fail after deployment, automatically revert to the previous known-good state.<\/li>\n
- Sign container images and verify signatures before deployment using Cosign or Notary.<\/li>\n
- Use immutable tags or digest-based references for container images to prevent tag-based attacks.<\/li>\n<\/ul>\n\n
Common Misconfigurations<\/h2>\n\n
Even teams that understand GitLab CI security concepts often fall into these traps:<\/p>\n\n
1. Unprotected Variables Containing Production Secrets<\/h3>\n\n
This is the most common and most dangerous misconfiguration. If a production database password is stored as an unprotected variable, any developer can create a branch, add an echo $DB_PASSWORD<\/code> step, and read it from the job log. Always protect and mask production secrets.<\/p>\n\n2. Overly Permissive Shared Runners<\/h3>\n\n
Shared runners with Docker socket mounting (\/var\/run\/docker.sock<\/code>) or --privileged<\/code> mode give jobs full control of the host. A malicious job can escape the container, access other jobs’ data, or compromise the runner itself.<\/p>\n\n3. Unrestricted CI_JOB_TOKEN Scope<\/h3>\n\n
Without explicit token scoping, a compromised job in a low-value project can use its CI_JOB_TOKEN<\/code> to access APIs and registries of high-value projects. Enable token scope restrictions on every project.<\/p>\n\n4. Missing Pipeline Validation on Merge Requests<\/h3>\n\n
If pipelines are not required to succeed before merging, attackers can push code that bypasses security scans. Enable the “Pipelines must succeed” setting.<\/p>\n\n
5. Hardcoded Secrets in .gitlab-ci.yml<\/h3>\n\n
It sounds obvious, but credentials still appear in pipeline YAML files with alarming frequency. Use CI variables, external secret managers, or OIDC \u2014 never inline a secret.<\/p>\n\n
6. No Audit Logging or Monitoring<\/h3>\n\n
GitLab generates audit events for CI\/CD configuration changes, but many organizations do not ship these logs to a SIEM or set up alerts. Without monitoring, compromises can go undetected for weeks.<\/p>\n\n
7. Stale Runner Registrations<\/h3>\n\n
Runners that were registered months ago and forgotten can have outdated configurations, unpatched operating systems, or overly broad project access. Audit and clean up stale runners regularly.<\/p>\n\n
Implementation Checklist<\/h2>\n\n
Use this checklist to systematically harden your GitLab CI\/CD environment. Prioritize items based on your threat model and compliance requirements.<\/p>\n\n
Variables and Secrets<\/h3>\n\n\n- \u2610 All production secrets are marked as protected and masked.<\/li>\n
- \u2610 Environment-scoped variables are used to separate staging and production credentials.<\/li>\n
- \u2610 No secrets are hardcoded in
.gitlab-ci.yml<\/code> or repository files.<\/li>\n- \u2610 Secret rotation schedule is documented and enforced.<\/li>\n
- \u2610 An external secrets manager (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager) is integrated for high-sensitivity credentials.<\/li>\n<\/ul>\n\n
Runners<\/h3>\n\n\n- \u2610 Production deployment runners are project-scoped and protected.<\/li>\n
- \u2610 Shared runners use ephemeral, containerized executors.<\/li>\n
- \u2610 Privileged mode is disabled or restricted to dedicated runner groups.<\/li>\n
- \u2610 Runner registration tokens are rotated regularly.<\/li>\n
- \u2610 Stale runner registrations are audited and removed quarterly.<\/li>\n<\/ul>\n\n
Environments and Deployments<\/h3>\n\n\n- \u2610 Production and staging environments are protected.<\/li>\n
- \u2610 Deployment approvals are enabled for production (Premium\/Ultimate).<\/li>\n
- \u2610 Manual gates are configured for production deployments.<\/li>\n
- \u2610 Rollback procedures are documented and tested.<\/li>\n
- \u2610 Container images are signed and verified before deployment.<\/li>\n<\/ul>\n\n
Tokens and Authentication<\/h3>\n\n\n- \u2610
CI_JOB_TOKEN<\/code> scope is restricted on every project.<\/li>\n- \u2610 OIDC
id_tokens<\/code> are used instead of static cloud credentials.<\/li>\n- \u2610 Cloud IAM trust policies validate project path, ref, and environment claims.<\/li>\n
- \u2610 Personal access tokens with CI\/CD scope are minimized and audited.<\/li>\n<\/ul>\n\n
Pipeline and Merge Request Settings<\/h3>\n\n\n- \u2610 “Pipelines must succeed” is enabled for all protected branches.<\/li>\n
- \u2610 Secret detection and SAST templates are included in the default pipeline.<\/li>\n
- \u2610 Push rules reject commits with known secret patterns.<\/li>\n
- \u2610
.gitlab-ci.yml<\/code> changes require approval from security reviewers.<\/li>\n- \u2610 Fork pipelines are sandboxed or require manual approval.<\/li>\n<\/ul>\n\n
Monitoring and Compliance<\/h3>\n\n\n- \u2610 Audit events for CI\/CD configuration changes are shipped to a SIEM.<\/li>\n
- \u2610 Alerts are configured for suspicious activity (e.g., new runner registrations, variable changes, unexpected deployments).<\/li>\n
- \u2610 Compliance pipelines (Ultimate) enforce mandatory security jobs across all projects.<\/li>\n
- \u2610 Regular access reviews cover runner permissions, variable access, and environment deployments.<\/li>\n<\/ul>\n\n
For a printable, at-a-glance version of these recommendations, see our GitLab CI Security Cheat Sheet<\/a>.<\/p>\n\nHands-On Lab<\/h2>\n\n
Reading about security is important, but practice makes it stick. Our interactive lab walks you through securing a real GitLab CI pipeline step by step \u2014 configuring protected variables, scoping runners, setting up environment approvals, and more.<\/p>\n\n
\ud83d\udc49 Lab: Securing GitLab CI Pipelines \u2014 Protected Variables, Runners & Environments<\/a><\/p>\n\nTools and Resources<\/h2>\n\n
The following tools and resources can help you assess and improve your GitLab CI\/CD security posture:<\/p>\n\n
GitLab-Native Security Features<\/h3>\n\n\n- Security Dashboard<\/strong> \u2014 centralized view of vulnerabilities across all projects in a group or instance.<\/li>\n
- Compliance Pipelines (Ultimate)<\/strong> \u2014 enforce mandatory CI jobs (like secret detection) that project maintainers cannot skip or modify.<\/li>\n
- Audit Events API<\/strong> \u2014 programmatic access to CI\/CD configuration change logs for integration with external SIEM platforms.<\/li>\n
- Dependency Scanning<\/strong> \u2014 identifies known vulnerabilities in project dependencies. Combine with secret detection for comprehensive supply-chain coverage.<\/li>\n
- Container Scanning<\/strong> \u2014 scans Docker images for OS-level and language-level vulnerabilities before they reach a registry.<\/li>\n<\/ul>\n\n
Third-Party and Open-Source Tools<\/h3>\n\n\n- Cimon<\/a><\/strong> \u2014 runtime security agent for CI\/CD that monitors and restricts network\/file access during pipeline execution.<\/li>\n
- StepSecurity Harden-Runner<\/a><\/strong> \u2014 originally for GitHub Actions, but the concepts (network egress filtering, process monitoring) apply to GitLab runners as well.<\/li>\n
- HashiCorp Vault<\/a><\/strong> \u2014 industry-standard secrets manager with native GitLab integration via the
vault<\/code> keyword in .gitlab-ci.yml<\/code>.<\/li>\n- Cosign<\/a><\/strong> \u2014 container image signing and verification. Integrate into your pipeline to sign images after build and verify before deployment.<\/li>\n
- Trivy<\/a><\/strong> \u2014 comprehensive vulnerability scanner for containers, filesystems, and Git repositories. Lightweight and easy to integrate into GitLab CI.<\/li>\n<\/ul>\n\n
Documentation and References<\/h3>\n\n\n- GitLab CI\/CD Pipeline Security Documentation<\/a><\/li>\n
- GitLab Runner Documentation<\/a><\/li>\n
- GitLab OIDC for Cloud Services<\/a><\/li>\n
- OWASP Top 10 CI\/CD Security Risks<\/a><\/li>\n<\/ul>\n\n
Conclusion<\/h2>\n\n
GitLab CI\/CD is a powerful, integrated DevSecOps platform \u2014 but its security is only as strong as your configuration. The controls exist: protected variables, runner scoping, environment approvals, OIDC federation, CI_JOB_TOKEN restrictions, secret detection, and deployment gates. The challenge is enabling them consistently and monitoring them continuously.<\/p>\n\n
Start with the highest-impact items: protect and mask all production secrets, scope your runners, restrict CI_JOB_TOKEN access, and enable secret detection in every pipeline. Then layer on OIDC for cloud authentication, deployment approvals for production environments, and compliance pipelines for organization-wide enforcement.<\/p>\n\n
Security is not a one-time configuration \u2014 it is an ongoing discipline. Review your pipeline security posture quarterly, audit access controls, rotate credentials, and stay current with GitLab’s evolving security features. With the practices in this guide, you will have a GitLab CI\/CD environment that is not just fast and productive, but genuinely secure.<\/p>\n\n
Ready to put these concepts into practice? Start with our GitLab CI Security Cheat Sheet<\/a> for a quick reference, then work through the hands-on lab<\/a> to build muscle memory. And for the broader context of credential management across all CI\/CD platforms, explore our guide to Short-Lived Credentials & Workload Identity Federation<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"GitLab CI\/CD has become the backbone of modern DevSecOps, offering an integrated platform where code, pipelines, security scanning, and deployments converge in a single interface. But that deep integration is a double-edged sword: a misconfigured pipeline can expose secrets, allow unauthorized deployments, or give attackers a foothold in your infrastructure. This definitive guide covers every … \u0627\u0642\u0631\u0623 \u0627\u0644\u0645\u0632\u064a\u062f<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26,30],"tags":[],"post_folder":[],"class_list":["post-752","post","type-post","status-publish","format-standard","hentry","category-ci-cd-security","category-gitlab-ci"],"_links":{"self":[{"href":"https:\/\/secure-pipelines.com\/ar\/wp-json\/wp\/v2\/posts\/752","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/secure-pipelines.com\/ar\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/secure-pipelines.com\/ar\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/secure-pipelines.com\/ar\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/secure-pipelines.com\/ar\/wp-json\/wp\/v2\/comments?post=752"}],"version-history":[{"count":2,"href":"https:\/\/secure-pipelines.com\/ar\/wp-json\/wp\/v2\/posts\/752\/revisions"}],"predecessor-version":[{"id":787,"href":"https:\/\/secure-pipelines.com\/ar\/wp-json\/wp\/v2\/posts\/752\/revisions\/787"}],"wp:attachment":[{"href":"https:\/\/secure-pipelines.com\/ar\/wp-json\/wp\/v2\/media?parent=752"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/secure-pipelines.com\/ar\/wp-json\/wp\/v2\/categories?post=752"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/secure-pipelines.com\/ar\/wp-json\/wp\/v2\/tags?post=752"},{"taxonomy":"post_folder","embeddable":true,"href":"https:\/\/secure-pipelines.com\/ar\/wp-json\/wp\/v2\/post_folder?post=752"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}