BTP Object Store as a storage backend

[kwiatekus]

Description

Docker registry should be able to consume a secret resulting from binding a BTP Object Store service instance. Add a new storage option as part of docker-registry specification that allows passing a secret name containing binding from BTP Object Store:

spec:
  storage:
     btpObjectStore:
         secretName: btp-object-store-binding-secret

AC

• [x] BTPObjectStore option should be mutually exclusive with other option
• [x] when BTPObjectStore storage is used, the operator should detect which of the hyperscaler variants (*) is used and auto-configure. backend without any manual configuration for specific fields (like bucket, region, keys, etc..)
• [x] after succesful reconciliation, operator should write back the detected variant to the status field ( i.e status.storage: btp-objectstore-(gcs/aws/azure)

Testing strategy New unit test expected for secret parsing of the 3 service binding variants.

Manual test scenario: Create 3 subaccounts on SAP BTP:

• on azure
• on gcp

• on aws

  In each of them configure entitlements for object store and create service instance of BTP Object Store. In each subaccount create service binding to produce secret. Create secret in kyma cluster and configure it id dockerregistry CR.

Reasons

Possibility for automatic configuration for storage backend based on any of the hyperscaler based variant is super convenient for the BTP users as they wouldn't need to extract the BTP object store binding secret and configure docker registry manually. Docker Registry Operator should come up with auto-configuration auto-pilot

Attachments

*) BTP Object Store - Azure variant BTP Object Store - GCS variant BTP Object Store - AWS(S3) variant