{"id":1725,"date":"2025-02-12T17:15:48","date_gmt":"2025-02-12T17:15:48","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2025\/02\/12\/a-smoother-hcp-terraform-workspace-experience\/"},"modified":"2025-02-12T17:15:48","modified_gmt":"2025-02-12T17:15:48","slug":"a-smoother-hcp-terraform-workspace-experience","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2025\/02\/12\/a-smoother-hcp-terraform-workspace-experience\/","title":{"rendered":"A smoother HCP Terraform workspace experience"},"content":{"rendered":"

HCP Terraform allows organizations to scale the management of their cloud infrastructure. However, onboarding multiple teams with unique requirements and workflows introduces its own set of challenges. This blog post will demonstrate how you can automate your HCP Terraform workspace setup by using the TFE provider and building an onboarding module.<\/p>\n

A common scenario<\/h2>\n

To illustrate a common scenario, imagine a tech company. We\u2019ll call them \u201cHashiCups\u201d. Their platform team<\/a> has successfully built their initial cloud landing zones using HCP Terraform. <\/p>\n

Cloud landing zone:<\/strong> A pre-configured, secure, and scalable environment that serves as a foundation for deploying and managing cloud resources.<\/p>\n

Now they\u2019re ready to make their first attempt at on-boarding an application team to HCP Terraform, with many more teams to follow. They realize that manually creating and configuring workspaces for each team is time-consuming and prone to errors. They need an automated onboarding process that’s not only efficient but also scalable and consistent.<\/p>\n

They\u2019ve decided they\u2019re going to add another abstraction layer to codify and automate the onboarding setup for HCP Terraform workspaces, teams and processes. They\u2019ll do this using Terraform as the engine once again, with the TFE provider<\/a>.<\/p>\n

With this provider they can build a reusable Terraform module (we\u2019ll call it the \u201cworkspace onboarding module\u201d) that encapsulates best practices for workspace creation, permission management, and team onboarding. This approach should allow HashiCups to scale effortlessly as they bring more teams into their infrastructure as code ecosystem.<\/p>\n

Onboarding the first team<\/h2>\n

The HashiCups platform team will start their onboarding process by having a meeting with the application team. To prepare for this meeting, they\u2019ll review their objectives.<\/p>\n

The platform team has two main objectives here:<\/p>\n

Get the application team up and running as quickly as possible.
\nCreate and test their reusable onboarding pattern (which is codified in a Terraform module) so that they can iron out any issues before they offer it to other teams.<\/p>\n

Based on these objectives, in their first meeting, they will ask:<\/p>\n

If the team is familiar with workspaces in HCP Terraform and provide an overview if necessary.
\nWhat their environment landscape looks like (the promotion path i.e. path from dev>test>prod).
\nWho should be permitted to change infrastructure configuration, and if those permissions depend on the environment.<\/p>\n

What is an HCP Terraform workspace?<\/h3>\n

In HCP Terraform, a workspace<\/a> is a fundamental concept that is used to organize infrastructure as code, so it makes sense to start the meeting reviewing what workspaces are and what\u2019s the impact on the team\u2019s IaC code.<\/p>\n

An HCP Terraform workspace is an isolated environment where a specific team or working group can manage a specific set of infrastructure resources. Each workspace maintains its own state file, which is important for tracking the current state of your infrastructure and ensuring that Terraform can accurately plan and apply changes to it. It provides a collaborative space for teams to manage infrastructure as code, with capabilities such as version control integration, secure state management, and role-based access control.<\/p>\n

Workspace scoping recommendations<\/h3>\n

Our recommended practice is that you structure your HCP Terraform setup so that each workspace corresponds to a specific: <\/p>\n

Business unit
\nApplication name
\nInfrastructure layer
\nPromotion path environment (i.e. dev>test>prod)
\nand\/or region <\/p>\n

Some example workspace names for a simple application following this recommendation could include:<\/p>\n

bu1-billing-prod-us-east
\nbu1-billing-staging-us-east<\/p>\n

For more complex scenarios, teams will need to divide their workspaces into even smaller scopes. If they have a large number of resources to deploy that becomes harder to manage and decipher. For example:<\/p>\n

bu2-orders-networking-prod-us-east
\nbu2-orders-compute-prod-us-east
\nbu2-orders-db-prod-us-east
\nbu2-orders-networking-staging-us-east
\nbu2-orders-compute-staging-us-east
\nbu2-orders-db-staging-us-east<\/p>\n

The main takeaway here is you can delineate your workspace scopes according to how you think you should isolate each environment to ensure three things: <\/p>\n

Adequately limiting the potential impact or ‘blast radius’ of any change-related failures
\nPreventing performance degradations from affecting other workspaces
\nAccommodating different infrastructure sizing and configuration needs for development, testing, and production scenarios<\/p>\n

The requirements<\/h3>\n

After asking the questions listed earlier and building a general understanding of workspaces and how they can be scoped, the HashiCups platform team has gotten a set of requirements from the application team. <\/p>\n

The application team explained that they use a 3-environment landscape (development, staging and production), which will translate into three workspaces. Through meetings with other stakeholders, such as security, operations leadership, and platform team leadership (sometimes these best-practice-building groups are called a \u201ccenter of cloud excellence (CCoE)\u201d), the platform team has an additional set of requirements for HCP Terraform workspace default settings:<\/p>\n

Each application team should have a group that is responsible for workspace administration and another group that has the necessary permissions to use the workspaces.
\nPowerful data removal commands like terraform destroy should not be allowed for production. Only development and staging environments.
\nTechnical leadership has decided on workspace naming conventions. Each name will have only two pieces of information: An application identifier, followed by an environment identifier (<application>-<environment>), and the workspace name must be in lowercase.
\nGenerally the environment used by the end users must use the prod environment identifier.<\/p>\n

After completing the discovery process,the platform team can now create the first version of the workspace onboarding module.<\/p>\n

Making the onboarding pattern reusable<\/h2>\n

The workspace onboarding module will generate the workspaces needed for the first application team. Rather than hardcoding their team-specific requirements into the workspace, the onboarding module will have empty variable fields so that any team in the organization can use the same module to customize workspaces for their own specific needs. For example, while the first team had 3 environments, some teams have 2 environments, and some teams have more than 3 environments. The number of environments generated will need to be a variable field in the module.<\/p>\n

Create the variable definitions<\/h3>\n

The first file we\u2019ll create is the variables.tf file, where we\u2019ll define four variables<\/a>:<\/p>\n

application_id, to hold the application (unique) identifier.
\nadmin_team_name, to hold the name of the (pre-existing) HCP Terraform team representing the application administrators.
\nuser_team_name, to hold the name of the (pre-existing) HCP Terraform team representing the application infrastructure engineers (or developers).
\nenvironment_names, to hold the list of environment names (dev, prod, etc.) in this application\u2019s environment landscape.<\/p>\n

The environment_names variable also needs a validation block to ensure that there is an environment named prod, as per the organization\u2019s requirements.<\/p>\n

variable “environment_names” {
\n description = “A list of environment names”
\n type = list(string)<\/p>\n

validation {
\n condition = contains([for env in var.environment_names : lower(env)], “prod”)
\n error_message = “The list of environment names must contain ‘prod’.”
\n }
\n}<\/p>\n

variable “admin_team_name” {
\n description = “The name of the team for the workspace administrators”
\n type = string
\n}<\/p>\n

variable “user_team_name” {
\n description = “The name of the team for the workspace users”
\n type = string
\n}<\/p>\n

variable “application_id” {
\n description = “The identifier of the application”
\n type = string
\n}<\/p>\n

Create the workspaces<\/h3>\n

The next step is creating the main.tf file, where admins will define the workspaces and team permissions. When creating the workspace for the prod environment, the team configures it so that destroy plans aren\u2019t allowed, as per the organization\u2019s requirements. They\u2019ll also use string interpolation to name the workspace according to the organization\u2019s naming convention. See how this looks in the configuration below.<\/p>\n

resource “tfe_workspace” “workspace” {
\n for_each = toset(var.environment_names)<\/p>\n

name = “${lower(var.application_id)}-${lower(each.value)}”
\n description = “Workspace for the ${each.value} environment of application ${var.application_id}”
\n allow_destroy_plan = each.value == “prod” ? false : true<\/p>\n

}<\/p>\n

data “tfe_team” “admin_team” {
\n name = var.admin_team_name
\n}<\/p>\n

data “tfe_team” “user_team” {
\n name = var.user_team_name
\n}<\/p>\n

resource “tfe_team_access” “admin_team_access” {
\n for_each = toset(var.environment_names)<\/p>\n

workspace_id = tfe_workspace.workspace[each.value].id
\n team_id = data.tfe_team.admin_team.id
\n access = “admin”
\n}<\/p>\n

resource “tfe_team_access” “user_team_access” {
\n for_each = toset(var.environment_names)<\/p>\n

workspace_id = tfe_workspace.workspace[each.value].id
\n team_id = data.tfe_team.user_team.id
\n access = “write”
\n}<\/p>\n

Note that this example is using data sources to fetch information about the admin_team and the user_team. An alternative would be to accept the team ID instead of the team name as an input variable. Using the team ID as an input variable can simplify the code and make it more efficient in terms of data processing. However, it may also make it less intuitive for a human to understand the input at a glance.<\/p>\n

Make outputs available<\/h3>\n

One of the key principles in infrastructure as code is composition. Composition in the context of IaC and Terraform refers to the practice of building complex configurations by combining smaller, reusable components. This approach enables modular, scalable, and maintainable infrastructure definitions.<\/p>\n

To enable composition with modules, the team needs to share information using outputs<\/a>. In this case, they made the IDs of the workspaces created for the application team available, as well as the IDs of the admin and user teams in the outputs.tf file:<\/p>\n

output “workspace_ids” {
\n description = “The IDs of the created workspaces”
\n value = { for k, v in tfe_workspace.workspace : k => v.id }
\n}<\/p>\n

output “admin_team_ids” {
\n description = “The IDs of the admin teams”
\n value = data.tfe_team.admin_team.id
\n}<\/p>\n

output “user_team_ids” {
\n description = “The IDs of the user teams”
\n value = data.tfe_team.user_team.id
\n}<\/p>\n

For a more in-depth discussion about outputs in Terraform, have a look at this discussion from HashiConf 2024: Meet the experts: Terraform module design<\/a>. <\/p>\n

Module tests<\/h3>\n

At this point, the team has a working module, but it\u2019s still missing an important component: Terraform tests<\/a>. These tests are necessary to ensure that as engineers improve the module they do not introduce bugs or break existing functionality.<\/p>\n

Terraform tests live under the tests directory in the module code repository.<\/p>\n

Test setup<\/h4>\n

The first step when writing a test suite is to ensure that the prerequisites are available. In this case, the prerequisites are the HCP Terraform teams for the workspace administrators and the workspace users.<\/p>\n

To define the prerequisites, the platform team will create the file tests\/testing\/setup\/main.tf with the following content:<\/p>\n

resource “tfe_team” “admin_team” {
\n name = “admins-test”
\n}<\/p>\n

resource “tfe_team” “user_team” {
\n name = “users-test”
\n}<\/p>\n

Test suite<\/h4>\n

The next step is to write the test suite. The platform team will create tests that ensure that the validation code on the environment_names variable works as expected.<\/p>\n

To define the test suite, they\u2019ll create the file tests\/environment_landscape_validation.tftest.hcl with the following content:<\/p>\n

provider “tfe” {
\n organization = “”
\n}<\/p>\n

variables {
\n admin_team_name = “admins-test”
\n user_team_name = “users-test”
\n application_id = “my-app”
\n}<\/p>\n

run “setup” {<\/p>\n

module {
\n source = “.\/tests\/testing\/setup”
\n }
\n}<\/p>\n

run “invalid_environment_landscape_missing_prod_name” {<\/p>\n

command = plan<\/p>\n

variables {
\n environment_names = [“dev”, “staging”]
\n admin_team_name = var.admin_team_name
\n user_team_name = var.user_team_name
\n application_id = var.application_id
\n }<\/p>\n

expect_failures = [var.environment_names]<\/p>\n

}<\/p>\n

run “invalid_environment_landscape_incorrect_prod_name” {<\/p>\n

command = plan<\/p>\n

variables {
\n environment_names = [“dev”, “staging”, “production”]
\n admin_team_name = var.admin_team_name
\n user_team_name = var.user_team_name
\n application_id = var.application_id
\n }<\/p>\n

expect_failures = [var.environment_names]<\/p>\n

}<\/p>\n

run “valid_environment_landscape” {<\/p>\n

command = plan<\/p>\n

variables {
\n environment_names = [“dev”, “staging”, “prod”]
\n admin_team_name = var.admin_team_name
\n user_team_name = var.user_team_name
\n application_id = var.application_id
\n }<\/p>\n

}<\/p>\n

run “workspace_name_in_lowercase” {<\/p>\n

command = plan<\/p>\n

variables {
\n environment_names = [“Dev”, “Staging”, “Prod”]
\n admin_team_name = var.admin_team_name
\n user_team_name = var.user_team_name
\n application_id = “My-App”
\n }<\/p>\n

assert {
\n condition = alltrue([for ws in tfe_workspace.workspace : lower(ws.name) == ws.name])
\n error_message = “All workspace names must be in lowercase.”
\n }
\n}<\/p>\n

The test suite above does the following:<\/p>\n

Provides a valid TFE provider configuration to use.
\nEnsures that the test prerequisites are present.
\nValidates that passing an invalid environment landscape is detected and fails the plan operation. An invalid environment landscape is either missing the prod environment or is using an incorrect name such as production.
\nValidates that passing a valid environment landscape is successful.
\nValidates that passing an application ID and\/or environment names with capitalized letters still result in the workspace name being in all lowercase.
\nTears down the test prerequisites.<\/p>\n

Running the test suite<\/h4>\n

Executing the test suite requires access to HCP Terraform. Prior to running the test suite, the platform team will need to generate an API token with permissions to create teams and make it available to their execution environment. Here is an example of how to do this on Linux:<\/p>\n

export TFE_TOKEN=<replace with the API token><\/p>\n

Executing the test suite is easy from the command line:<\/p>\n

terraform test<\/p>\n

Terraform will discover the available tests and execute them, reporting on the results:<\/p>\n

tests\/invalid_environment_landscape.tftest.hcl… in progress
\n run “setup”… pass
\n run “invalid_environment_landscape_missing_prod_name”… pass
\n run “invalid_environment_landscape_incorrect_prod_name”… pass
\n run “valid_environment_landscape”… pass
\n run “workspace_name_in_lowercase”… pass
\ntests\/invalid_environment_landscape.tftest.hcl… tearing down
\ntests\/invalid_environment_landscape.tftest.hcl… pass<\/p>\n

Success! 5 passed, 0 failed.<\/p>\n

Provide documentation and examples<\/h4>\n

When developing a Terraform module, it is highly recommended to include two essential files: a comprehensive documentation file and a detailed changelog.<\/p>\n

The documentation file, named README.md, serves as a valuable resource for users of the module, providing clear instructions on its purpose, usage, input variables, outputs, and any specific requirements or dependencies. This documentation ensures that other team members or future maintainers can quickly understand and effectively utilize the module without extensive reverse engineering.<\/p>\n

Equally important is the changelog file, named CHANGELOG.md, which records all notable changes and version increments for the module over time. The changelog acts as a historical record, allowing users to track modifications, understand the evolution of the module, and make informed decisions about upgrades. Together, these files significantly enhance the module’s usability, maintainability, and overall quality, fostering better collaboration and reducing potential issues arising from lack of information or miscommunication.<\/p>\n

Example README.md file:<\/p>\n

# Terraform Workspaces Module<\/p>\n

## Description<\/p>\n

This module configures one or more workspaces for an application team, with one workspace corresponding to one SDLC environment. It uses the TFE provider to create workspaces in HCP Terraform.<\/p>\n

## Usage<\/p>\n

“`hcl
\nmodule “workspaces” {
\n source = “path\/to\/your\/module”
\n environment_names = [“dev”, “staging”, “prod”]
\n admin_team_name = “admin-team”
\n user_team_name = “user-team”
\n application_id = “my-app”
\n}
\n“`<\/p>\n

## Inputs<\/p>\n

| Name | Description | Type | Default | Required |
\n|——————-|————————————————–|————-|————-|———-|
\n| environment_names | A list of environment names | list(string)| n\/a | yes |
\n| admin_team_name | The name of the team for the workspace administrators | string | n\/a | yes |
\n| user_team_name | The name of the team for the workspace users | string | n\/a | yes |
\n| application_id | The identifier of the application | string | n\/a | yes |<\/p>\n

## Outputs<\/p>\n

| Name | Description |
\n|———————|——————————————|
\n| workspace_ids | The IDs of the created workspaces |
\n| admin_team_ids | The IDs of the admin teams |
\n| user_team_ids | The IDs of the user teams |<\/p>\n

Example CHANGELOG.md file:<\/p>\n

# Changelog<\/p>\n

## [1.0.0] – 2025-01-XX
\n### Added
\n– Initial version of the Terraform module.
\n– Added support for creating workspaces in Terraform Cloud using the TFE provider.
\n– Added variables for environment names, admin team name, user team name and application ID.
\n– Added validation to ensure the environment names list contains “prod”.
\n– Added outputs for workspace IDs, admin team IDs, and user team IDs.
\n– Added tests to validate the environment names and workspace name formatting.<\/p>\n

Recap and possible enhancements<\/h2>\n

Using an example scenario and company, this blog post has shown how to gather requirements to automate the creation of workspaces for an application team and translate those requirements into a reusable Terraform module, complete with code, documentation, and automated tests. Once created, the module should be published and used by future teams adopting HCP Terraform. You can learn more about publishing your module in this tutorial: Share modules in the private registry<\/a>.<\/p>\n

We intentionally used a simplified scenario to keep the post to a reasonable length and easy to understand, but some readers may argue that certain important aspects were omitted, and they\u2019d be right. Let\u2019s cover those aspects and flag them as potential enhancements to the example solution:<\/p>\n

Introduce HCP Terraform projects<\/a>
\nConfigure workspace notifications<\/a>
\nUse dynamic provider credentials<\/a>
\nModule lifecycle management<\/a><\/p>\n

HCP Terraform projects<\/strong> are used to group together multiple related workspaces and simplify configuration by allowing RBAC, variable sets, policy sets to be configured at the project level, rather than at the workspace level, easing the management burden.<\/p>\n

It generally makes sense to create an HCP Terraform project per application team, and in our scenario, we could update the module to create a project and register all workspaces under it.<\/p>\n

You can learn more about using HCP Terraform projects in this tutorial: Organize workspaces with projects<\/a>.<\/p>\n

Workspace notifications<\/strong> enable HCP Terraform to send notifications about run progress and other significant events to external systems, such as Slack, Microsoft Teams, or via email. Each workspace can have its own notification settings, allowing up to 20 different notification destinations per workspace.<\/p>\n

In our scenario, the platform team could update the module to configure workspace notifications that trigger on the following events:<\/p>\n

Workspace events<\/p>\n

Drift (HCP Terraform detected a configuration drift)
\nCheck failure (HCP Terraform detected one or more failed continuous validation checks), if your code includes checks.<\/p>\n

Run events<\/p>\n

Needs attention (a plan has changes and HCP Terraform requires user input to continue).
\nErrored (a run terminated early due to an error or cancellation)<\/p>\n

Dynamic provider credentials<\/strong> in HCP Terraform represent a significant advancement in security and access management. This feature allows Terraform to automatically generate short-lived credentials for cloud providers on-demand, rather than relying on long-term, static access keys. When a Terraform operation is initiated, HCP Terraform requests temporary credentials from the cloud provider that are valid only for the duration of the specific task.<\/p>\n

This approach substantially improves the security posture by minimizing the exposure window of access credentials, reducing the risk of unauthorized access if credentials are compromised. Additionally, it eliminates the need to manage and manually rotate long-term access keys, decreasing administrative overhead and the potential for human error in credential management.<\/p>\n

You can learn more about using dynamic provider credentials in this tutorial: Authenticate providers with dynamic credentials<\/a>. <\/p>\n

Module lifecycle management<\/strong> is a systematic approach to control and maintain Terraform modules from rollout to retirement, provide module status visibility, and improve communication across teams. Key aspects of module lifecycle management include:<\/p>\n

Version control<\/strong>: Modules are tracked in version control systems to maintain history and allow collaboration between modules maintainers.
\nTesting<\/strong>: Writing and executing tests for your module code lets you check if everything works correctly before publishing a new version.
\nPublishing new versions<\/strong>: Releasing an updated copy of your module in a private registry<\/a> with new features or fixes, similar to releasing a new version of an application.
\nDeprecation handling<\/strong>: The ability to mark modules as deprecated and communicate when modules should no longer be used.<\/p>\n

The module in this post is designed to onboard a new application team, but it could, with minor changes, also apply to shared services maintained by a platform team: The application_id variable could be renamed shared_service_id and this would be the start of a good foundation for shared services. As a platform team engineer, you can create a module to not only speed up the onboarding of new teams but also solve onboarding for shared services that your team manages.<\/p>\n

Additional resources<\/h2>\n

Automate HCP Terraform workflows<\/a>
\nTry HCP Terraform\u2019s free tier<\/a> which includes up to 500 resources per month.<\/p>","protected":false},"excerpt":{"rendered":"

HCP Terraform allows organizations to scale the management of their cloud infrastructure. However, onboarding multiple teams with unique requirements and […]<\/p>\n","protected":false},"author":0,"featured_media":0,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[6],"tags":[],"class_list":["post-1725","post","type-post","status-publish","format-standard","hentry","category-terraform"],"_links":{"self":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/1725","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/comments?post=1725"}],"version-history":[{"count":0,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/1725\/revisions"}],"wp:attachment":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/media?parent=1725"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/categories?post=1725"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/tags?post=1725"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}