Resource status field contains request body with sensitive data and proxy value is not considered from environment variables

[iamshinto]

What happened?

We used disposable request to make an API call to generate access token. The provider is not considering the proxy environment variables added to the provider pod. We have created a PR #38 to read proxy from environment for the http client.

After building the provider locally with the proxy settings as descirbed in PR #38 we were able to make the API call. The disposable request is working as expected but the object status has the sensitive token data populated. Would you be so kind to look into this and mitigate this issue.
status:

Status:
  Conditions:
    Last Transition Time:  2024-07-25T10:34:44Z
    Reason:                Available
    Status:                True
    Type:                  Ready
    Last Transition Time:  2024-07-25T10:34:44Z
    Reason:                ReconcileSuccess
    Status:                True
    Type:                  Synced
  Last Reconcile Time:     2024-07-25T10:35:47Z
  Request Details:
    Body:  {
  "grant_type": "refresh_token",
  "refresh_token": "{{ secretname:namespace:key }}"
}

    Headers:
      User - Agent:
        provider-http-test
    Method:  POST
    URL:     https://login.example.com/oidc/token
  Response:
    Body:  {"access_token":"{{response-secret:namespace:accesstoken}}","expires_in":3600,"refresh_token":"unencryptedtoken","token_type":"Bearer"}

    Headers:
      Content - Length:
        1024
      Content - Type:
        application/json
      Date:
        Thu, 25 Jul 2024 10:35:45 GMT
      Server:
        istio-envoy
      X - Envoy - Upstream - Service - Time:
        103
    Status Code:  200
  Synced:         true

How can we reproduce it?

Please use PR #38 to build and create disposable request againt any API with access token in the request body

What environment did it happen in?

Crossplane version: 14.5

Regards,
Shinto Vincent

[arielsepton]

Hey,

Thank you for your contribution.

To ensure that sensitive data from the response body is stored securely and not displayed in the status, you should add secretInjectionConfigs to your DisposableRequest YAML. This configuration will ensure that sensitive data is stored in a secret and not exposed in the status.

You can refer to the example for more details.

Your DisposableRequest YAML should include a secretInjectionConfigs section like this:

secretInjectionConfigs: 
  - secretRef:
      name: response-refresh-token
      namespace: default
    secretKey: extracted-token
    responsePath: .body.refresh_token

With this configuration, the response should be updated to look like this:

Body:  {"access_token":"{{response-secret:namespace:accesstoken}}","expires_in":3600,"refresh_token":"{{response-refresh-token:default:extracted-token}}","token_type":"Bearer"}

This will ensure that the refresh_token is stored securely in a Kubernetes secret and not exposed in the status.

Let me know if this helps!

[iamshinto]

Hi @arielsepton,

Thanks for looking into this issue. I am already using this and is writing the response to a secret. I was talking about the input itself.
We are trying to generate an access token using a refresh token. The refresh token is supplied in to the disposable request in the request body to be read from a kubernetes secret. So if I describe a disposablerequest object, in the spec it will look like

Spec:
  Deletion Policy:  Orphan
  For Provider:
    Body:  {
  "grant_type": "refresh_token",
  "refresh_token": "{{ request_secret:namespace:key }}"
}

The response of the secret is masked as you said but I can see the refresh token I have used in the request in the status of disposable request.

Response:
Body: {"access_token":"{{response-secret:namespace:accesstoken}}","expires_in":3600,"refresh_token":"decrypted-secret","token_type":"Bearer"}

I tried testing the API via postman to see if this key is returned in the response but it didn't. I don't know why the key from request body is added to the response. The actual response looks like

{
  "access_token": "redacted",
  "expires_in": "3600",
  "token_type": "Bearer"
}

[arielsepton]

Thank you for the clarification @iamshinto

If I understand correctly, your DisposableRequest spec looks exactly like the example you provided, with no extra fields. I would appreciate it if you could share the entire DisposableRequest yaml to get a complete picture.

Additionally, you mentioned that you are seeing an extra field in the response of the request when using DisposableRequest, which is not present when you test the API via Postman. Are you certain that the request and response configurations in Postman match those in your DisposableRequest? Specifically, did you ensure that all headers, body parameters, and the protocol used are identical in both cases?

[iamshinto]

Nevermind, the response has this field. I tested with the wrong API. Thanks again @arielsepton