feat: bump API version; add suspend feature in sops object; make sops:data to map to secret:data (was secret:stringData) and sops:stringData to secret:stringData

[isindir]

What this PR does / why we need it:

This PR introduces #63 - data and stringData

, but instead of mapping:

• sops:data -> secret:stringData
• sops:binaryData -> secret:data

it does 1-to-1 mapping:

• sops:data -> secret:data
• sops:stringData -> secret:stringData

in sops definition both can be combined.

Suspend feature

Introduces sops:spec.suspend boolean flag to disable given sops object reconciliation (by example from FluxV2 types)

[travisghansen]

Is there a sort of upgrade guide associated with this set of changes? Are both api versions still served or will updating break everything and/or delete existing sopssecrets?

In short, what are the recommended series of steps to upgrade?

[isindir]

@travisghansen , that is distruptive change - depending on your setup it could be more or less involved. In short:

• operator does not support both API versions at the same time
• it is not possible to apply 2 CRDs at the same time (old and new) - just checked that

That means - upgrade is a 2 phase disruptive operation - uninstall + remove crd (this should drop all existing managed secrets and sops secrets) and then installation.

I think operationally this is a lot easier when using gitops (not tested). Perhaps I need to think about better upgrade plan in future and introduce managing multiple API versions via conversion webhooks.

[isindir]

@travisghansen just had another thought - may be I can improve following if:

https://github.com/isindir/sops-secrets-operator/pull/76/files#diff-67f21185a11c234dac59fe4d2e98aee91f765b84760cbb92055895e294fe1ed0R291

by applying raw text value if it is not base64 encoded value like it was in the past, just printing our warning - but not having damaging effect on the status of the resource, wdyt ? I need to try it via upgrade as well - if that will work, I'll cook new PR shortly. This way it will potentially be possible to upgrade helm chart over and then gradually fix all the sopssecret objects.

[isindir]

That strategy I mentioned unlikely to work. I have tried following now:

• apply v1alpha2
• helm install
• apply sops object of v1alpha2
• helm upgrade (operator restarted and started to fail - due to missing CRD version v1alpha3)
• kubectl apply -f v1alpha3 --force=true (all secrets were immediately vanished)
• apply sops object of v1alpha3 (operator recreated all the secrets)

I guess the only nondistruptive way is via scaling down original version of operator and then modifying all managed secrets to become non managed and then upgradeing all re-applying new version of sops objects and removing (now) not managed secrets, so that operator can recreate these.

However I think applying raw value of the not encoded data field may be still usefull in certain cases.

[travisghansen]

I’ll do a bit more research/testing myself as well and report back any findings.

I don’t understand the relevance of your last sentence in this case. The new format mimics 100% secret syntax right? data should be pre-encoded and stringData is not pre-endcoded right?

[isindir]

don’t understand the relevance of your last sentence in this case. The new format mimics 100% secret syntax right? data should be pre-encoded and stringData is not pre-endcoded right?

Correct

However I think applying raw value of the not encoded data field may be still usefull in certain cases.

• if data was not pre-encoded by mistake, it still can be added as is, but also triggering user notification in logs. This situation also would not put the whole sops object in error state.

[travisghansen]

So with the new release data can be either base64 or not base64?

[isindir]

So with the new release data can be either base64 or not base64?

In case I change if statement mentioned above, it would have that behaviour, atm it is not.