Consideration for making backup-restore https server to be mTLS enabled

[anveshreddy18]

Enhancement (What you would like to be added):

Backup Restore https server can be considered for mTLS enablement.

Motivation (Why is this needed?):

Currently the backup-restore https server is only TLS enabled, I would like it to be mTLS where the server also verifies the client certificates to enhance the security.

In the Gardener landscapes, we do generate the client certificates to be used by clients connecting to backup-restore server and is mounted to the respective container but the backup-restore server is not configured to verify client's identity thus the cert-key pair is rendered useless.

When deployed through druid, the clients that currently connect to the backup-restore container is only etcd-wrapper which triggers the initialisation procedure, getting etcd config, etc. But, in future there are plans to take out of schedule snapshots from etcd-druid as well for which it needs to make the api request to the backup-restore server, so making the server mTLS makes more sense keeping the future plans in mind.

Approach/Hint to the implement solution (optional):

[unmarshall]

Is mTLS is required at this stage given that the server is only being consumed by etcd-wrapper?

But, in future there are plans to take out of schedule snapshots from etcd-druid as well for which it needs to make the api request to the backup-restore server, so making the server mTLS makes more sense keeping the future plans in mind.

Why do we assume that etcd-druid is going to make a direct HTTPs call to etcd-backup-restore server to take full snapshots? When the operator tasks are implemented there will be CR created for every task which will be accessible also from within etcd-backup-restore container which will then update the status of these tasks.

[anveshreddy18]

After an out-of-band discussion with @unmarshall, we have come to conclusion that having the server mTLS enabled will be beneficial in cases when etcdbr is used standalone for taking etcd backups mainly for open-source consumption and also that other communication lines like etcd and kapi are mutual TLS enabled so enabling mTLS on etcdbr server also makes sense as it is a critical service and the access to that should only be given to authorised clients.

This can be considered when the work on etcd-steward starts.

[unmarshall]

This can be considered when the work on etcd-wrapper starts.

I think you meant when the work on etcd-steward starts :)

Additionally for etcd-wrapper <-> etcd-backup-restore communication line using mTLS might be an overkill as they already share a network namespace. So if we have to enable mTLS then it has to be for use cases where consumers call HTTP(s) APIs exposed out of etcd-backup-restore.