Merge pull request #8957 from harness/s-n-idp-dp-3

feat: [IDP]: Added warning message for delegate proxy usage and an example usage of dynamic picker

docs/internal-developer-portal/flows/dynamic-picker.md

@@ -54,11 +54,11 @@ Go to IDP Admin -> Plugins. Find the plugin called "Configure Backend Proxies".
 
 Inside the plugin, you get three options (like any other [IDP plugin configuration](https://developer.harness.io/docs/internal-developer-portal/plugins/overview)).
 
-1. Declare a Backend Proxy endpoint and headers
+1. Declare a Backend Proxy (HTTP Proxy) endpoint and headers
 2. Configure necessary secrets
-3. Configure Delegate Proxy (in case the API is not publicly accessible, or the secret is on your infrastructure)
+3. Configure Delegate Proxy (Delegate HTTP Proxy) (in case the API is not publicly accessible, or the secret is on your infrastructure)
 
-In order to set up a proxy to connect with GitHub APIs, you can add the following in the configuration YAML
+In order to set up a HTTP proxy to connect with GitHub APIs, you can add the following in the configuration YAML
 
 ```yaml
 proxy:
@@ -81,6 +81,14 @@ In the `headers` you can add an Authorization header. Ensure you use a unique to
 
 ![](./static/example-proxy-backend-config.png)
 
+Configure a Delegate HTTP Proxy to route traffic through an HTTP proxy using Delegate. This is useful when we need to access private endpoints not publicly accessible. 
+
+:::warning
+Endpoints targeting the `harness.io` domain should **not** be configured behind a **Delegate HTTP Proxy**, as you are already in the Harness infrastructure. Using a Delegate HTTP Proxy in this case is unnecessary, as direct access is inherently available. 
+:::
+
+![](./static/delegate-proxy.png)
+
 Hit "Save Configuration" and now our backend proxy is ready to use!
 
 You can verify this endpoint by making requests to the `proxy` endpoint at `https://idp.harness.io/{ACCOUNT_IDENTIFIER}/idp/api/proxy/`. For example in order to test the GitHub example above, you can make a request to
@@ -322,3 +330,54 @@ properties:
 ### Advanced processing the API response
 
 If the filters here are not sufficient for your use case, and you require additional data processing of the response, then we recommend you setting up a Lambda function in your cloud provider or a lightweight backend to do this job. You can use your Backend Proxy and Delegate Proxy to communicate to your custom Lambda/Backend.
+
+## Example Usage
+
+### Fetch the list of Harness Services in Workflows
+
+1. Configure the [Backend Proxy](#step-1-create-a-backend-proxy)
+
+Set up a backend proxy in the plugin configuration to enable API calls to Harness. 
+
+```YAML
+proxy:
+  endpoints:
+    /harness-api-endpoint:
+      target: https://app.harness.io
+      pathRewrite:
+        /api/proxy/harness-api-endpoint/?: /
+      headers:
+        x-api-key: ${PROXY_HARNESS_TOKEN}
+```
+
+- `/harness-api-endpoint`: Proxy path for the Harness API.
+- `x-api-key`: Add your Harness Personal Access Token as an environment variable(covered in the next step).. 
+
+2. Add the [Harness Personal Access Token](https://developer.harness.io/docs/platform/automation/api/add-and-manage-api-keys/#create-personal-api-keys-and-tokens) as a variable. Save the token as an environment variable named `PROXY_HARNESS_TOKEN`.
+
+3. Update your Workflow definition YAML to include a dropdown for fetching the list of services.
+
+```YAML
+## Example workflows.yaml
+...
+properties:
+  service:
+    type: string
+    ui:field: SelectFieldFromApi
+    ui:options:
+      title: Choose the service
+      description: Pick one of the service you want to deploy
+      placeholder: "Choose a service"
+      allowArbitraryValues: true
+      path: proxy/harness-api-endpoint/ng/api/servicesV2?page=0&size=100&accountIdentifier=ACCOUNT_ID&orgIdentifier=ORG_ID&projectIdentifier=PROJECT_ID&includeAllServicesAccessibleAtScope=true
+      valueSelector: 'service.name'
+      arraySelector: 'data.content'
+...
+```
+- `ui:field`: Configures the dropdown to fetch data from an API.
+- `path`: API endpoint for fetching the list of services. You need to add the account identifier in place of `ACCOUNT_ID`, organization identifier in place of `ORG_ID` and project identifier in-place of `PROJECT_ID`.
+- `valueSelector`: Extracts the service name for the dropdown values.
+- `arraySelector`: Extracts the array containing the services
+
+For a complete example, refer to the [sample Workflows YAML](https://github.com/harness-community/idp-samples/blob/main/tutorial-dynamic-picker-examples.yaml).
+

docs/internal-developer-portal/plugins/delegate-proxy.md

@@ -19,15 +19,19 @@ Harness IDP supports the following the types pf plugins in terms of accessing th
 
 | Term               | Definition                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              |
 | ------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| **Backend Proxy**  | Harness IDP has a feature called Backend Proxy also known as [ Backstage Proxy ](https://backstage.io/docs/plugins/proxying/) or Plugin Proxy - that can be used to add proxy routes in the backend for third party APIs. A Backend Proxy is needed when a plugin requires authentication and the tokens need to be stored in the backend. This proxy can be used to handle tasks such as HTTP termination, CORS handling, injecting static secrets (e.g., Authorization headers), and leveraging other proxy features like retries, failover, health checks, routing, request logging, and rewrites. Take a look at an example of how the Backend Proxy looks in [Harness IDP plugin configurations](https://developer.harness.io/docs/internal-developer-portal/plugins/available-plugins/pagerduty/#application-configuration-yaml). |
-| **Delegate Proxy** | Delegate Proxy in IDP is an HTTP interceptor in the backend which helps plugins connect to systems which are not accessible from the Harness SaaS platform. They use a [ Harness Delegate ](/docs/platform/delegates/delegate-concepts/delegate-overview/) which is a service you run in your local network or VPC to connect your artifacts, infrastructure, collaboration, verification, and other providers with Harness.                                                                                                                                                                                                                                                                                                                                                                                                            |
+| **Backend Proxy (HTTP Proxy)**  | Harness IDP has a feature called Backend Proxy also known as [ Backstage Proxy ](https://backstage.io/docs/plugins/proxying/) or Plugin Proxy - that can be used to add proxy routes in the backend for third party APIs. A Backend Proxy is needed when a plugin requires authentication and the tokens need to be stored in the backend. This proxy can be used to handle tasks such as HTTP termination, CORS handling, injecting static secrets (e.g., Authorization headers), and leveraging other proxy features like retries, failover, health checks, routing, request logging, and rewrites. Take a look at an example of how the Backend Proxy looks in [Harness IDP plugin configurations](https://developer.harness.io/docs/internal-developer-portal/plugins/available-plugins/pagerduty/#application-configuration-yaml). |
+| **Delegate Proxy (Delegate HTTP Proxy)** | Delegate Proxy in IDP is an HTTP interceptor in the backend which helps plugins connect to systems which are not accessible from the Harness SaaS platform. They use a [ Harness Delegate ](/docs/platform/delegates/delegate-concepts/delegate-overview/) which is a service you run in your local network or VPC to connect your artifacts, infrastructure, collaboration, verification, and other providers with Harness.                                                                                                                                                                                                                                                                                                                                                                                                            |
 
-## When is a Delegate Proxy needed?
+## When is a Delegate HTTP Proxy needed?
 
 There are two scenarios when you need to add a Delegate Proxy when configuring an IDP plugin (including custom plugins).
 
-1. A Delegate Proxy is needed when you have a plugin which needs to connect to an internal system of yours which is not accessible directly from the Harness SaaS platform. For example, [the Kubernetes plugin](https://developer.harness.io/docs/internal-developer-portal/plugins/available-plugins/kubernetes/#delegate-proxy).
-2. A Delegate Proxy is also needed if the secrets used in the Plugin's configuration are not stored in Harness built-in secret manager, but are stored on your own infrastructure (e.g. Cloud Provider's secret manager, HashiCorp Vault, etc.)
+1. A Delegate  HTTP Proxy is needed when you have a plugin which needs to connect to an internal system of yours which is not accessible directly from the Harness SaaS platform. For example, [the Kubernetes plugin](https://developer.harness.io/docs/internal-developer-portal/plugins/available-plugins/kubernetes/#delegate-proxy).
+2. A Delegate HTTP Proxy is also needed if the secrets used in the Plugin's configuration are not stored in Harness built-in secret manager, but are stored on your own infrastructure (e.g. Cloud Provider's secret manager, HashiCorp Vault, etc.)
+
+:::warning
+Endpoints targeting the `harness.io` domain should **not** be configured behind a **Delegate HTTP Proxy**, as you are already in the Harness infrastructure. Using a Delegate HTTP Proxy in this case is unnecessary, as direct access is inherently available. 
+:::
 
 ## Architecture Diagrams