SCTL is not End2End encryption, instead SCTL is more of an envelope, in which you store secrets until they are needed, and those secrets should only remain available in plain text while the operation that needs them is active.
I can see a case for using GCP Secrets Manager as a backend with sctl, effectively using sctl to load / recall the values. This would have an impact on a lot of assumptions sctl has, such as looking for envelopes on the filesystem.
GSM would fully replace the need for the envelope format, and would likely become a thin shim of URI identifiers for the secrets contained in GSM.
This needs more thought, and an analysis of if it's even feesible, but it sounds like a good means to offload envelope and DVCS holding secrets, into a more isolated system, still gate-kept by cloud IAM policies.
I can see a case for using GCP Secrets Manager as a backend with sctl, effectively using sctl to load / recall the values. This would have an impact on a lot of assumptions sctl has, such as looking for envelopes on the filesystem.
GSM would fully replace the need for the envelope format, and would likely become a thin shim of URI identifiers for the secrets contained in GSM.
This needs more thought, and an analysis of if it's even feesible, but it sounds like a good means to offload envelope and DVCS holding secrets, into a more isolated system, still gate-kept by cloud IAM policies.