Add "--allow-empty-values" flag

[volodymyrZotov]

✨ Summary

Operator versions <= 1.9.x ignored fields with empty values and didn't include them in k8s secrets. In case if an item doesn't have default values set (aka password, username notes), it ignored them and k8 secret contained only field that had values set. For example:

data:
  my-api-key: YzJWamNtVjBNVEl6

v1.10.0 (PR) introduced a feature that allows to create k8s secret with empty values from the fields that has not value set.

That results in k8 secrets looks like this

data:
  my-api-key: YzJWamNtVjBNVEl6
  notesPlain: ""
  password: ""
  username: ""

There are some use cases when it's required to create k8s secret with empty value (like this). And for some users it breaks existing workflows as in #246, the operator should support both use cases.

To enable the support for both cases a new allow-empty-values flag is introduced.

By default the flag is set to false. That will support backward compatibility and for the users that used versions <= v1.9x and will upgrade to the latest, nothing will change. Though, the users that relies on v1.10.x behavior (want's empty values) will need to redeploy their operator with --allow-empty-values=true.

🔗 Resolves: #246

✅ Checklist

• 🖊️ Commits are signed
• 🧪 Tests added/updated: (See the Testing Guide for when to use each type and how to run them)
  • 🔹 Unit
  • 🔸 Integration
  • 🌐 E2E (Connect) - as covered by integration and unit tests, e2e can be skipped.
  • 🔑 E2E (Service Account)
• 📚 Docs updated (if behavior changed)

🕵️ Review Notes & ⚠️ Risks

Should be tested with Connect, as the issue can be reproduced only with Connect.

SDK(when using with service account) and Connect have a mismatch in returned response.
SDK doesn't return fields with empty values at all. In a contrast Connect does return all the fields.
Future SDK releases should have a fix for that, and SDK version used by the operator should be upgraded. Issue to track this #249

How to test steps:

Create an item in 1password that have no default fields set (username, password, notes) but having only custom field with any value.

1. Checkout to vzt/allow-empty-values-flag branch
2. minikube start
3. eval $(minikube docker-env)
4. export OP_CONNECT_TOKEN=your_token
5. Refer to these instructions to find out how to create k8s secrets required for Connect.
6. make docker-build
7. Set MANAGE_CONNECT env var to true in config/manager/manager.yaml
8. make deploy
9. kubectl apply secret.yaml -> create you CR
10. kubectl get secret secret_name -o yaml
11. Check that data within the secret contains only the field that is populated in 1password item. Password, username, note fields are not in k8s secret.
12. Update config/manager/manager.yaml, and pass --allow-empty-values=true flag. (add it below this line).
13. Re-deploy operator
14. Wait polling interval (10m by default), or remove secret and re-create it.
15. kubectl get secret secret_name -o yaml
16. Check that data within the secret contains all the field, including empty password, username, notes.

[JillRegan]

Love this 👏 Thank you so much!

I left a small comment but I will leave it up to you how you wish to approach. Approved ✅

[kdambekalns]

This does not solve it for people that might need both ways, right? #145 was added because someone needed empty values. For others that broke, they need those values to be left out. What if I need both, in different secrets, for different consumers?

[volodymyrZotov]

@kdambekalns What do you mean by "both"?

With thin PR it will ignore empty values by default. If flag --allow-empty-values=true is set, then secrets will have empty values.

For example, there is 1password item. It has 1 field with value (A), and another field which is empty (B).

By default secret will contain only A (only the field with value).
With --allow-empty-values=true set, it will contain both A and B.

You can also control this on your side by creating 1password item with the values you need.
For example enable the flag --allow-empty-values=true, then create item A with all the fields containing values, then item B with some empty fields.

Does this cover the scenarios you are thinking about?