Feature Request: If ETCD is Encrypted, Store static_kuberesources.tgz on a Different Storage

[eyenx]

Hello,

I would like to propose a feature enhancement for the openshift-etcd-backup process. Specifically, when ETCD is encrypted, it would be beneficial to store the static_kuberesources.tgz file on a different storage location. This change would enhance the security and integrity of the backup process, especially in scenarios where encryption is a critical part of the data protection strategy.

Current Behavior:

Currently, when ETCD is encrypted, the static_kuberesources.tgz file, which holds the encryption keys for ETCD, is stored along with the rest of the backup files. This setup could potentially expose sensitive data, including the encryption keys, if the primary backup storage is compromised.

Proposed Behavior:

When ETCD is encrypted, modify the backup process to store the static_kuberesources.tgz file on a different, specified storage location. This could be a different bucket in the same cloud storage service or an entirely separate storage solution. The configuration for the alternative storage location should be flexible and allow for various types of storage backends.

Benefits:

• Enhanced Security: Separating the storage of encrypted data and static Kubernetes resources, which includes the encryption keys, reduces the risk of exposing sensitive information.
• Compliance: Helps in meeting regulatory and compliance requirements that mandate the separation of certain types of data.
• Flexibility: Provides more options for backup strategies and storage management.

Implementation Details:

• Introduce a new configuration option in the openshift-etcd-backup tool to specify an alternative storage location for static_kuberesources.tgz.
• Ensure the backup and restore processes are updated to handle the new storage configuration.
• Provide clear documentation on how to configure and use this feature.

Additional Context:

This feature is particularly important for environments with strict security requirements and can greatly enhance the overall robustness of the backup and restore process in OpenShift deployments.