Contrast workload secrets leak to logs on INFO level

Summary

### Impact When the Contrast initializer is configured with a `CONTRAST_LOG_LEVEL` of `info` or `debug`, the workload secret is logged to `stderr` and written to Kubernetes logs. Since `info` is the default setting, this affects all Contrast installations that don't customize their initializers' log level. The following audiences are **intended** to have access to workload secrets (see https://docs.edgeless.systems/contrast/1.7/architecture/secrets#workload-secrets): * Contrast Coordinator (can derive all workload secrets) * Contrast Initializer (obtains only the secret configured in the manifest) * Seedshare owner (can derive all workload secrets) * Workload owner (can update manifests to obtain secrets) This vulnerability allows the following parties **unintended access** to workload secrets issued by a Coordinator: * Kubernetes users with `get` or `list` permission on `pods/logs`. * Others with read access to the Kubernetes log storage (most notably, the cloud provider). This vulnerability **does not affect** scenarios where workload secrets are not used by the application (directly or with [secure persistence](https://docs.edgeless.systems/contrast/1.7/architecture/secrets#secure-persistence)). Applications designed for workload owner exclusion can't use workload secrets and are thus unaffected. ### Patches N/A ### Workarounds This vulnerability can be mitigated by adding an environment variable `CONTRAST_LOG_LEVEL=warn` to the initializer after running `contrast generate`, and then running `contrast generate` again. ### References N/A