Updating credentials manifest resets other non-exposed fields in API

[wizrds]

Preflight checklist

• I could not find a solution in the existing issues, docs, nor discussions.
• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines.
• I have joined the Ory Community Slack.
• I am signed up to the Ory Security Patch Newsletter.

Ory Network Project

No response

Describe the bug

We self host hydra as well as the maester in our k8s cluster. We have created some credentials by adding a new manifest and applying it. Afterwards, the client_credentials_grant_access_token_lifespan was manually updated (since it isn't exposed in the credentials manifest schema) to a non-default value of 5 hours.

Later on, the manifest for those credentials were updated by adding a new redirect URI item to the list, then applied again. Afterwards, the response from the hydra API for those credentials showed that the client_credentials_grant_access_token_lifespan was no longer the value we set but reset back to the default None.

This shouldn't happen as not only does that field not even exist in the CRD but it wasn't explicitly changed at all.

Reproducing the bug

1. Setup hydra and hydra-maester in k8s environment
2. Create new OAuth2Client manifest with configuration and apply
3. Manually update client_credentials_grant_access_token_lifespan to a different value via hydra API
4. Add new redirect URI and apply again in previous manifest
5. client_credentials_grant_access_token_lifespan is reset

Relevant log output

No response

Relevant configuration

No response

Version

Hydra v2.2.0 and Hydra Maester v0.0.33-amd64

On which operating system are you observing this issue?

Linux

In which environment are you deploying?

Kubernetes

Additional Context

No response

[wizardist]

Token lifespans have been implemented in #145.

That doesn't address the original issue though - the controller is using PUT endpoint instead of PATCH endpoint.

If you expect reconciliation to work both ways (CR --> Ory && Ory --> CR), then for sure, would seem to be a better solution. But then there's currently no logic in the controller to support bidi reconciliation.