OAuth Bad Credentials with TLS Configuration

[Wojciech Wrzalik]

#397 introduced backward compatibility mode. While testing this functionality I have discovered that by generating certs in BTP using {"credential-type":"x509"} json input those values do not work when used in sap-btp-service-operator-tls. If clientsecret and TLS data is not present in sap-btp-service-operator secret fallbacks to reading it from sap-btp-service-operator-tls. However, if clientsecret is not present, then communication with service manager fail with the following error message oauth2: \"invalid_client\" \"Bad credentials\""}. I am not sure how and if sap-btp-service-operator-tls is an alternative for oauth or just its extension to provide additional layer of security. Current implementation disables TLS certs for customers that have sap-btp-service-operator-tls and sap-btp-service-operator defined.

[Naama Solomon]

Hi @ralikio

If my understanding is correct, you have created both 'sap-btp-service-operator' and 'sap-btp-service-operator-tls' secrets.
Could you please provide details on the fields contained within these secrets and how this was done?

Thanks,
Naama

[Wojciech Wrzalik]

Hello @I065450,

the issue has been discovered on the kyma cluster. I have created two secrets sap-btp-service-operator and sap-btp-service-operator-tls in default namespace on top of sap-btp-service-operator in `kyma-system.

kind: Secret
apiVersion: v1
metadata:
  name: sap-btp-service-operator
  namespace: default
  labels:
    app.kubernetes.io/managed-by: btp-manager
    chart-version: v0.6.1
data:
  clientid: "..."
  clientsecret: "" # empty string
  cluster_id: "..."
  sm_url: "..."
  tokenurl: "..."
  tokenurlsuffix: "..."
type: Opaque

kind: Secret
apiVersion: v1
metadata:
  name: sap-btp-service-operator-tls
  namespace: default
  labels:
    app.kubernetes.io/name: sap-btp-service-operator-tls
data:
  tls.crt: "valid cert tested with smctl login command without client_secret - base64"
  tls.key: "valid key tested with smctl login command without client_secret - base64"
type: kubernetes.io/tls

For test purpose I created the following instance definition:

apiVersion: services.cloud.sap.com/v1
kind: ServiceInstance
metadata:
  labels:
    app.kubernetes.io/name: rectangular-freedom
spec:
  externalName: rectangular-freedom
  serviceOfferingName: auditlog-management
  servicePlanName: default

[Naama Solomon]

Hi @ralikio

I have rechecked your scenario, and everything appears to be functioning correctly.
Please validate all attributes in the secret, particularly ensure that the token URL has been adjusted to fit TLS.

Regards,
Naama

[Wojciech Wrzalik]

@I065450 works as you described it. Thank you for your help.