sap / sap-btp-service-operator Goto Github PK

Chart fails on helm lint sapbtp-operator-charts command, with the following error:

==> Linting .
[INFO] Chart.yaml: icon is recommended
[ERROR] templates/: template: sap-btp-operator/templates/secret.yml:17:49: executing "sap-btp-operator/templates/secret.yml" at <b64enc>: invalid value; expected string

Error: 1 chart(s) linted, 1 chart(s) failed

When I create ServiceBinding, the userInfo section is correctly represented as

  userInfo:
    groups:
    - mps-logging-admin
    - mps-monitoring-viewer
    - skr-logging-admin
    - mps-monitoring-admin
    - runtimeAdmin
    - runtimeOperator
    - skr-monitoring-admin
    - skr-logging-viewer
    - mps-logging-viewer
    - skr-monitoring-viewer
    - system:authenticated
    username: [email protected]

But after few reconciles, it changes to btp-operator service account before it pronounces the bindings as ready.

  userInfo:
    groups:
    - system:serviceaccounts
    - system:serviceaccounts:sap-btp-operator
    - system:authenticated
    uid: 3d2203e0-5b76-4177-9b7f-ed6b0b878264
    username: system:serviceaccount:sap-btp-operator:default

sb.watch.yaml.log
btp-operator.log

Hi there,

is there a plan for making HANA Cloud available via the BTP service operator?

BR,
Tobias

I just tried to create these resources:

cloud-logging-service.yaml

apiVersion: services.cloud.sap.com/v1alpha1
kind: ServiceInstance
metadata:
  name: my-logging-instance
spec:
  serviceOfferingName: cloud-logging
  servicePlanName: standard
---
apiVersion: services.cloud.sap.com/v1alpha1
kind: ServiceBinding
metadata:
  name: my-logging-binding
spec:
  serviceInstanceName: my-logging-instance
  secretName: mySecret

But this error appears:

conditions:
    - lastTransitionTime: '2021-11-25T20:47:23Z'
      message: >-
        Error sending request GET
        https://dev-ufn0iae5.authentication.sap.hana.ondemand.com/v1/service_instances?attach_last_operations=true&fieldQuery=name+eq+%27my-logging-instance%27+and+context%2Fclusterid+eq+%274272aeda-b2c8-4472-afd9-a979e00b7e20%27+and+context%2Fnamespace+eq+%27default%27&labelQuery=_k8sname+eq+%27my-logging-instance%27:
        Get
        https://dev-ufn0iae5.authentication.sap.hana.ondemand.com/v1/service_instances?attach_last_operations=true&fieldQuery=name+eq+%27my-logging-instance%27+and+context%2Fclusterid+eq+%274272aeda-b2c8-4472-afd9-a979e00b7e20%27+and+context%2Fnamespace+eq+%27default%27&labelQuery=_k8sname+eq+%27my-logging-instance%27:
        Post /oauth/token: unsupported protocol scheme ""
      observedGeneration: 1
      reason: InProgress
      status: 'False'
      type: Succeeded
    - lastTransitionTime: '2021-11-25T20:47:23Z'
      message: ''
      reason: NotProvisioned
      status: 'False'
      type: Ready

Anything I'm doing wrong on my end?

More context for debugging

kustomization.yaml

resources:
  - https://github.com/jetstack/cert-manager/releases/download/v1.6.1/cert-manager.yaml
  - namespace.yaml
  - cloud-logging-service.yaml

helmCharts:
  - name: sap-btp-operator
    repo: https://sap.github.io/sap-btp-service-operator
    version: v0.1.18
    releaseName: sap-btp-operator
    namespace: sap-btp-system
    includeCRDs: true
    valuesFile: sap-btp-values.yaml

sap-btp-values.yaml

manager:
  secret:
    clientid: XXX
    clientsecret: XXX
    url: https://dev-ufn0iae5.authentication.sap.hana.ondemand.com
    xsappname: XXX
    sm_url: https://service-manager.cfapps.sap.hana.ondemand.com

Hi @misappi
As it temp organization do we need to to something besides adding the source files?
I mean github actions etc...

Hello,

Background: We have multiple applications deployed in BTP Cockpit in Cloud Foundry env. And they share and bind the same service instances such as xsuaa broker, audit log, which are created in the same subaccount in Cloud Foundry. We have also some applications deployed in k8s env, which to reuse these service instances by coping service key of these instances to the environment, to remote access these services. Now we plan to use btp-service-operator to access the service instances

Question: After trying the btp service operator, we find that we cannot bind existing cloud foundry service instances in k8s env. And we also cannot bind the service instance in cloud foundry created by btp-service-operator. It seems that service instances in both env are isolated. So my question is how to bind service instances that exist in cloud foundry via service operator? If not, is there any other official solution to access these service instances from k8s environment?

Thanks a lot!

BTP Service Operator (v1.1.14) failed to create servicebindings though the serviceinstance was created successfully. In this case, I would expect the operator will try to handle the servicebinding later. But it seemed not. Here is the status of servicebinding:

 
status:  conditions:  - lastTransitionTime: "2021-12-17T10:19:43Z"    message: |      ServiceBinding create failed: request POST https://service-manager.cfapps.us10.hana.ondemand.com/v1/service_bindings failed: StatusCode: 404 Body: {"error":"NotFound","description":"could not find such instance"}    observedGeneration: 1    reason: CreateFailed
    status: "False"    type: Succeeded
  - lastTransitionTime: "2021-12-17T10:19:43Z"    message: ""    reason: NotProvisioned
    status: "False"    type: Ready
  - lastTransitionTime: "2021-12-17T10:19:43Z"    message: |      ServiceBinding create failed: request POST https://service-manager.cfapps.us10.hana.ondemand.com/v1/service_bindings failed: StatusCode: 404 Body: {"error":"NotFound","description":"could not find such instance"}    observedGeneration: 1    reason: CreateFailed
    status: "True"    type: Failed
  observedGeneration: 1  ready: "False"

When creating ServiceBinding for a ServiceInstance created by the operator, it frequently fails in my case.

$ k get serviceinstance
NAME                  OFFERING       PLAN      STATUS    READY   AGE
my-service-instance   auditlog-api   default   Created   True    2m48s

$ k get serviceinstance my-service-instance -o json | jq '.status.instanceID'
"71215544-0588-4458-af27-7c5d1a621815"

$ k get servicebinding
NAME         INSTANCE              STATUS         READY   AGE
my-binding   my-service-instance   CreateFailed   False   71s

$ k get servicebinding my-binding -o json | jq '.status.conditions[0].message'
"ServiceBinding create failed: request POST https://service-manager.cfapps.sap.hana.ondemand.com/v1/service_bindings failed: StatusCode: 409 Body: {\"error\":\"Conflict\",\"description\":\"binding with same name exists for instance with id 71215544-0588-4458-af27-7c5d1a621815\"}

Both service instance as well as binding get created and are visible in BTP Cockpit, but I suspect that the controller may be faster than the k8s cache update and potentially puts itself in a race condition in

In the installation description it is mention, that we should/must install the jetstack cert-manager.
Maybe it should be possible to use the Gardener provided cert-manager as well. This reduce the amount of
components to install.

I think the BTP-Operator is mainly use within the BTP environment and for this reason gardener or kyma is the 90% case, isn't it?

When running helm lint ./helm/umbrella-charts/cluster-base-btp-service-operator we get this error in our pipeline:

==> Linting ./helm/umbrella-charts/cluster-base-btp-service-operator
[ERROR] templates/: template: cluster-base-btp-service-operator/charts/sap-btp-operator/templates/secret.yml:17:49: executing "cluster-base-btp-service-operator/charts/sap-btp-operator/templates/secret.yml" at <b64enc>: invalid value; expected string

Error: 1 chart(s) linted, 1 chart(s) failed

it relates to: https://github.com/SAP/sap-btp-service-operator/blob/main/sapbtp-operator-charts/templates/secret.yml Lin 17.

Proposal:

{{- if .Values.manager.secret.b64encoded }}
data:
  clientid: {{ .Values.manager.secret.clientid | quote }}
  {{- if .Values.manager.secret.clientsecret }}
  clientsecret: {{ .Values.manager.secret.clientsecret | quote }}
  {{- end }}
  url: {{ .Values.manager.secret.url | quote }}
  tokenurl: {{ .Values.manager.secret.tokenurl | quote }}
  tokenurlsuffix: {{ .Values.manager.secret.tokenurlsuffix | quote }}
{{- else}}
stringData:
  clientid: {{ .Values.manager.secret.clientid | quote }}
  {{- if .Values.manager.secret.clientsecret }}
  clientsecret: {{ .Values.manager.secret.clientsecret | quote }}
  {{- end }}
  url: {{ .Values.manager.secret.url | quote }}
  tokenurl: {{ .Values.manager.secret.tokenurl | quote }}
  tokenurlsuffix: {{ .Values.manager.secret.tokenurlsuffix | quote }}
{{ end }}

To be able to use ArgoCD for deployment it is necessary for a helm-chart to be deployed declaratively. This is needed for our productive deployment as well later on.

In the case of btp-service-operator helm chart the mandatory parameters are confidential this hinders a declarative setup. In the past there were ways to circumvent this issue but these are not available anymore!

• Workaround -> not working anymore
• Using the --values parameter is also not going to work since these values are secret values and cant be stored for our declarative deployment in this way. (we use bitnami sealed secrets for this purposes)

The cleanest solution is to allow the operator to consume an already existing secret if the property is given!
In this case a setup similar to this example with some optional parameters fixes the helm chart installation:

# usual way (will not be changed)
helm upgrade --install <release-name> sap-btp-operator/sap-btp-operator \
    --create-namespace \
    --namespace=sap-btp-operator \        
    --set manager.secret.clientid=<clientid> \
    --set manager.secret.clientsecret=<clientsecret> \
    --set manager.secret.url=<sm_url> \
    --set manager.secret.tokenurl=<url>

# optional way (actually IMHO recommended way):
helm upgrade --install <release-name> sap-btp-operator/sap-btp-operator \
    --create-namespace \
    --namespace=sap-btp-operator \        
    --set manager.secret.create=< true (default) | false > \
    --set manager.secret.name=<default-secret-name> 

This way users can point to an existing secret and allow argoCD to deploy the helmchart and the operator can still get all of its needed information since it would be in the same namespace anyways.

Supporting this feature would allow adoption of the btp-service-operator in a simpler and more future proven way there is demand for this and it is also a better design for k8s deployments if there are confidential parameters (this is just my honest opinion here :) ) .
#115 #87

Implementation on operator side is simple:

if manager.secret.create == true
  helm values are filled
  normal behaviour as before
else
  retrieve values from the secret that is provided in manager.secret.name
  continue normal behaviour as before

Best regards,
Rudolf

The BTP Service Operator has a very important feature to bind a namespace to a specific subaccount overriding the binding from the service operator's namespace. There are even two ways to do this:

1. Create a secret with the name sap-btp-service-operator / sap-btp-service-operator-tls in the namespace that should be bound
2. Create a secret with the name <namespace>-sap-btp-service-operator / <namespace>-sap-btp-service-operator in the central namespace.

See:

Could you please add documentaion for these features. I think there is a configuration switch to enable 1. as well.

Thanks & Best regards,
Uwe

Question:

We installed one service instance of 'cloud logging Service' in our account in CF with quota = 1.
When installed successfully the service instance to the first K8s cluster with the following yaml:

apiVersion: services.cloud.sap.com/v1alpha1
kind: ServiceInstance
metadata:
  name: "logging-large"
  annotations:
    "helm.sh/hook": "post-install"
    "helm.sh/hook-weight": "1"
spec:
  serviceOfferingName: "cloud-logging"
  servicePlanName: "large"

On attempt to pair the second cluster with the same configuration file it failed with the following error message:
With error: Status: 403; ErrorMessage: Forbidden; Description: Quota is not sufficient for this request; ResponseError: \u003cnil\u003e"?

Is this the desire behavior / bug ?
Kindly advice.

regards,
Yoram Yair
Developer @ SAP

It would be useful to have the functionality that BtpServiceOperator could only act on resources in certain namespaces or with a certain label attached to them. That way multiple ServiceOperators, each attached to different BTP accounts could be installed in the same Kubernetes cluster.

Cloud Foundry has a feature that allows users to provide custom keys when the create service instances.

These tags will be injected via the VCAP_SERVICES environment variable along the tags coming from the catalog. It would be great if the ServiceInstance custom resource would support providing custom tags and if the controller would write these custom tags to the Secret.

Hey colleagues,

since you are publishing the operator as a helm chart, I was wondering if you could provide support for a values yaml where it is either possible to reference a secret that contains the credentials and/or writing the credentials directly into the values.yaml (the former would probably be better).

For the service catalog, we can install service-broker-proxy to achieve different namespaces mapping to different BTP subaccounts, which means, In one k8s cluster, we can provision BTP service instance for each BTP subaccount in different namespace.

To migrate btp-service-operator from the service catalog, how can I achieve this?
It seems that the clientid & clientSecret is provided during the installation of the btp operator.

We should correctly configure liveness and Readiness probe in the Deployment

Hey btp-service-operator team,

Kyma uses the btp-service-operator. Unfortunately, the default helm chart only supports jetstack/certificate-manager certificates. However, cert-manager is not a default component of a kyma environment. Therefore we created a custom helm chart supporting the following types of certificates:

• Self-Signed
• Jetstack Cert-Manager
• SAP Cert-Management

The helm chart we are using is currently located here: https://github.com/kyma-incubator/sap-btp-service-operator/tree/main/chart

It would be terrific if the official helm-chart provided by sap-btp-service-operator would be extensible enough, so we could get rid of ours.

Regards,
Christoph

Hi,

I were using btp-operator to create a destination service and xsuaa service and their bindings ,
and I deleted them and created them again.
Actually I can only see one destination service and one xsuaa service in the cluster,
However in the cockpit UI, I can see there are two destinations and two xsuaa services. Is there way to clean up old services in the cockpit UI, I cannot do any operation in the UI

Thanks,
George form SAP

Hi!

Kind of related to #83.
We are currently working on a feature to read service bindings from secrets created by the service operator.
For that we already create tickets #78 and #79.

This means that we right now would expect the secret to be created using the secretKey parameter, creating a single property with the credentials JSON as it's value.
The other properties (as added with #78) are then added in parallel to the single secretKey property.

This, however, might now lead to the issue, that those other properties could be "flattened" (so a list of entries is stored as a String "["value1", "value2"]").
From an SDK point of view we cannot know whether this is now a list or an actual String property.

Therefore the proposel to have an option to just store all properties into a single property.
The format of this could be guided by the usual CF VCAP_SERVICES, but could also be something "new".

Is there an ClientSet available to interact with K8s CRD Objects like https://pkg.go.dev/github.com/gardener/gardener/pkg/client/extensions/clientset/versioned?

I have to progamatically update an Service Instance of .Spec -> serviceOfferingName: identity servicePlanName: application -> parameters -> oauth2-configuration -> redirect-uris every time a new BTP Subaccount subscribes to my Service which creates an new Gardener Cluster.

Kind regards

Hello,

we are currently in a process of moving from "Service Catalog / Service Broker Proxy" based setup towards "SAP BTP Service Operator" and I am trying to compare their output from the BTP Sub-Account perspective.

Context

For having Service Catalog / Broker on your K8s Cluster, it was necessary to register that cluster as "platform":

smctl register-platform <platform-name> kubernetes

then all created service instances appeared under Sup-Account -> Instances and Subscriptions for a specific scope:

platform-name | k8s-namespace

Of course, it is possible to register multiple clusters as platforms, creating instances using the same name.

Now with SAP BTP Service Operator, instead of a "platform" it is necessary to create an instance of the Service Manager (service-operator-access service plan) and respective binding which values will be used as parameters when installing "sap-btp-operator" helm chart.

So far so good but after we start creating app-specific service instances, they appear as undefined in BTP Cockpit:

Questions

Now, finally the questions:

1. Is it planned to cooperate with BTP Cockpit colleagues to improve on that undefined situation? What actually will be shown instead of "platform" when Service Operator based setup is used?

2. If we now create multiple clusters, should we simply re-use already created instance of the Service Manager (service-operator-access service plan) and its binding to install "sap-btp-operator" helm chart or are we supposed to create new binding per cluster? What would be the procedure? Creating a new instance of the Service Manager (service-operator-access service plan) is not possible, since we are entitled to have one and only one instance per (provider) sub-account.

Thanks in advance,
Anton

I tried to add sap-btp-service-operator as a subchart of a umbrella helm chart

The issue is that the cert-manager has to be preinstalled before we can install the operator and in umbrella helm chart we have no influence on which chart to be install before or after another chart

May I ask for you advice?

Error when installing via helm:

Chart.yaml:

• name: sap-btp-operator
  version: "0.1.17"
  repository: "https://sap.github.io/sap-btp-service-operator"

"Error: unable to build kubernetes objects from release manifest: [unable to recognize "": no matches for kind "Certificate" in version "cert-manager.io/v1alpha2", unable to recognize "": no matches for kind "Issuer" in version "cert-manager.io/v1alpha2"]"

From https://github.com/jetstack/cert-manager/releases/tag/v1.6.0:

Breaking Changes (You MUST read this before you upgrade!)
⚠️ Following their deprecation in version 1.5, the cert-manager APIVersions v1alpha2, v1alpha3, and v1beta1 are no longer served.

Question: When will you convert/update update all your manifests from valpha to v1?

Hi colleagues,

is there any document or example of creating xsuaa instance by btp operator and how to pass the xs-securty.json as parameters?

And how to define the runtime environment and scope for my xsuaa broker.

I try the following but the status is stuck in createInProgress.

apiVersion: services.cloud.sap.com/v1alpha1
kind: ServiceInstance
metadata:
    name: my-xsuaa-instance
spec:
    serviceOfferingName: xsuaa
    servicePlanName: broker
    parameters:
      config:
        xs-security:
          xsappname: "ai-bus-sbf-test"
          authorities:
            - $XSAPPNAME.default
          scopes:
            - name: $XSAPPNAME.default
              description: Default grant access to all endpoints exposed by ai-bus-sbf-test

status:

Status:
  Conditions:
    Last Transition Time:  2021-11-09T06:38:27Z
    Message:               request POST https://service-manager.cfapps.sap.hana.ondemand.com/v1/service_instances failed: StatusCode: 503 Body: {"error":"Timeout", "description": "operation has timed out"}
    Observed Generation:   1
    Reason:                CreateInProgress
    Status:                False
    Type:                  Succeeded
    Last Transition Time:  2021-11-09T06:38:27Z
    Message:               
    Reason:                NotProvisioned
    Status:                False
    Type:                  Ready
  Observed Generation:     1
  Ready:                   False
Events:                    <none>

BTW is there any support channel in slack for btp operator, thanks.

Hi there,
we are using PodSecurityPolicies to harden our cluster. Among other things, these PSPs mandate that pods do not run as root.
However, the default user in the controller image is specified by name (nonroot) and thus the admission controller cannot determine if it is root or not (see K8s sources).
I'd like to change the Dockerfile so that the default user from the distroless image is referenced by uid and not by name (see here). So this change doesn't change the default user, just how it's referenced.

I opened #85 to implement this small change.

Thanks!

Description:
I have tried to create every Service Catalog instance and binding available to me at staging BTP Cockpit and then executed https://github.com/SAP/sap-btp-service-operator-migration. Some of the resources failed to get created because webhook server was not available. This happened due to crashlooping sap-btp-service-operator.

$ k get po -nsap-btp-operator
NAME                                                   READY   STATUS             RESTARTS   AGE
sap-btp-operator-controller-manager-595b76f4f8-xj65c   1/2     CrashLoopBackOff   7          28m

Version:

$ k get deployment -nsap-btp-operator -o json sap-btp-operator-controller-manager | jq '.spec.template.spec.containers[].image'
"gcr.io/kubebuilder/kube-rbac-proxy:v0.5.0"
"ghcr.io/sap/sap-btp-service-operator/controller:v0.1.9"

Attachments:
log from the migration tool: run.log
log from the sap-btp-service-operator: crashloop.log
yaml of service instance that appears to be crashlooping the operator: service-manager-whispered-part.serviceinstance.yaml.txt

Hi!

I'm part of the SAP Cloud SDK (Java) team and we are currently working on reading service bindings from K8S secrets, coming from CF with the bindings stored in the VCAP_SERVICES.
After discussion with @nenaraab we were thinking, that it could make sense that the Service Operator provides a library to read secrets as service bindings, kind of similar to the @sap/xsenv library for JavaScript.

Rough requirements would be:

• Being able to read a service binding from ...
  • ... secrets created by the service operator
  • ... environment variables (e.g. VCAP_SERVICES either on CF or "emulated" on K8S)
• Easy to extend with different reading logic, e.g. in case the secrets were created in a different way than "usual"

Do you have, by any chance, such a client library on the roadmap?

When trying to create service instance I get the following error.
Can you help ?

 'Error sending request GET /v1/service_instances?attach_last_operations=true&fieldQuery=name+eq+%27sdm-service%27+and+context%2Fclusterid+eq+%274c58a4d3-cc63-4f84-b882-c5fd85a163e8%27+and+context
%2Fnamespace+eq+%27ddbf6b8c-0124-41ff-84e9-dbef14e887dd%27&labelQuery=_k8sname+eq+%27sdm-service%27:
      Get /v1/service_instances?attach_last_operations=true&fieldQuery=name+eq+%27sdm-service%27+and+context%2Fclusterid+eq+%274c58a4d3-cc63-4f84-b882-c5fd85a163e8%27+and+context%2Fnamespace+eq+%27ddbf6b8c-01
24-41ff-84e9-dbef14e887dd%27&labelQuery=_k8sname+eq+%27sdm-service%27:
      Post : unsupported protocol scheme ""'

The helm chart seems to support Gardener Cert-Manager as an option. But I'm unable to find any documentation
how to use them. In the official README.md nor on the SAP Help is any reference how to use them.

https://github.com/SAP/sap-btp-service-operator#setup
https://help.sap.com/viewer/09cc82baadc542a688176dce601398de/Cloud/en-US/e977f23be2ed4cd9aa0b32704b37d77e.html

We want to use this option but we are unable to install the operator in that way.

Hi,

Does the pod spec in https://github.com/SAP/sap-btp-service-operator/blob/main/sapbtp-operator-charts/templates/deployment.yml really requires root access for its containers?

Is it possible to harden the definition by adding securityContext.runAsNonRoot?

Thanks

Hi Colleagues,

i have an issue while installing via Helm.

SM_OPERATOR_VERSION = v.0.1.18

helm upgrade --install sap-btp-operator https://github.com/SAP/sap-btp-service-operator/releases/download/$SM_OPERATOR_VERSION/sap-btp-operator-$SM_OPERATOR_VERSION.tgz \
    --create-namespace \
    --namespace=sap-btp-operator \
    --set manager.secret.clientid="$SM_CLIENTID" \
    --set manager.secret.clientsecret="$SM_CLIENTSECRET" \
    --set manager.secret.url=$SM_URL \
    --set manager.secret.tokenurl=$SM_TOKENURL

cert-manager version is v1.6.1
I use the credential of the service binding of my service manager instance.

by running 'kubectl get apiservices', I don't see "webhook.cert-manager.io" anymore?

Thanks and best regards!

When following the install instructions from https://github.com/SAP/sap-btp-service-operator#setup, the operator fails to start because of missing CRDs:

2021-06-09T07:40:30.113Z	ERROR	controller-runtime.source	if kind is a CRD, it should be installed before calling Start	{"kind": "ServiceInstance.services.cloud.sap.com", "error": "no matches for kind \"ServiceInstance\" in version \"services.cloud.sap.com/v1alpha1\""}
github.com/go-logr/zapr.(*zapLogger).Error
	/go/pkg/mod/github.com/go-logr/[email protected]/zapr.go:132
sigs.k8s.io/controller-runtime/pkg/source.(*Kind).Start
	/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/source/source.go:117
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func1
	/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:159
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start
	/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:205
sigs.k8s.io/controller-runtime/pkg/manager.(*controllerManager).startRunnable.func1
	/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/manager/internal.go:691
2021-06-09T07:40:30.113Z	INFO	controller-runtime.webhook	shutting down webhook server
2021-06-09T07:40:34.063Z	ERROR	controller-runtime.source	if kind is a CRD, it should be installed before calling Start	{"kind": "ServiceBinding.services.cloud.sap.com", "error": "no matches for kind \"ServiceBinding\" in version \"services.cloud.sap.com/v1alpha1\""}
github.com/go-logr/zapr.(*zapLogger).Error
	/go/pkg/mod/github.com/go-logr/[email protected]/zapr.go:132
sigs.k8s.io/controller-runtime/pkg/source.(*Kind).Start
	/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/source/source.go:117
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func1
	/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:159
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start
	/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:205
sigs.k8s.io/controller-runtime/pkg/manager.(*controllerManager).startRunnable.func1
	/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/manager/internal.go:691
2021-06-09T07:40:34.063Z	ERROR	setup	problem running manager	{"error": "no matches for kind \"ServiceInstance\" in version \"services.cloud.sap.com/v1alpha1\""}
github.com/go-logr/zapr.(*zapLogger).Error
	/go/pkg/mod/github.com/go-logr/[email protected]/zapr.go:132
main.main
	/workspace/main.go:122
runtime.main
	/usr/local/go/src/runtime/proc.go:203

LÍDER DE DESENVOLVIMENTO SAP BUSINESS TECHNOLOGY PLATFORM
Carreira técnica em desenvolvimento de sistemas e perfil hands-on
SAP BTP com foco em Application Development and Integration
SAP FIORI
Full-Stack (conhecimento em todas as etapas do desenvolvimento)
Ferramentas de ETL/orquestração de dados
Liderança de equipes de desenvolvimento
Imprescindível Inglês Fluente

Prazo: Indeterminado
Contratação: PJ
Local: Remoto durante a pandemia - Após a pandemia presencial em Alphaville
Envio de currículo: [email protected] indicando no assunto " Líder de desenvolvimento SAP Business Technology Platform - HM”
Em caso de dúvida ou informações=> WhatsApp: https://wa.me/message/BVQ5K5OO3AWEC1

Currently the btp operator flattens one level of binding information to the secret. It would be nice to have the option to configure a maximum depth to flatten so deep service keys can be used easier as environment variables.
For example there are service keys like this:

{
"uaa": { "url": "https://someorg.authentication.eu10.hana.ondemand.com/" }
}

currently this leads to a key in the secret being created called UAA which contain the entry

{ "url": "https://someorg.authentication.eu10.hana.ondemand.com/" }

it would be nice if there was a configuration option in the servicebinding option to flatten 2 (or more?) levels and create a key in the secret called UAA_URL which would contain the value https://someorg.authentication.eu10.hana.ondemand.com/

Bonus: if we could also get the option to specify a "prefix" for keys in the secret the secrets could directly map to spring boot environment variable bindings. So something like prefix: MY_PREFIX_ which would make the key MY_PREFIX_UAA_URL instead of just UAA_URL

CRDs should be moved to sapbtp-operator-charts/crds folder.
See relevant documentation: https://helm.sh/docs/topics/charts/#the-chart-file-structure

@avilupu @misappi We're ready for publishing to SAP, anything else from our side?
if not please migrate this repo.

If secret is not found in the resource namespace then it should be searched in management namespace. However, the code still searched in the resource namespace (as per the written code).
I think it needs a fix.

Hello,
in #84, secretRootKey was introduced which added the possibility to store all info (credentials & metadata) under one key.
However, when using Go, it's necessary to unmarshal twice, because the credentials are converted to string prior to marshalling.
E.g.,

myRootKey: '{
    "credentials": "{\"apiurl\":\"https://certificate-service.my.domain\",\"policy\":\"some-policy\",\"profileurl\":\"https://some.other.url/path\"}",
    "instance_guid": "000000-000-00-000-0000000",
    "instance_name": "my-instance",
    "label": "certificate-service",
    "plan": "standard"
}'

Would it be possible to remove this conversion somehow, so that users can access all infos with a single call to unmarshal?
Thanks!

Currently a fixed strategy is applied to transform the service key generated to a kubernetes secret. It would be nice that if in addition to the current strategy in place an advanced templating mechanism could be used similar to what's provided by "external secrets operator" (https://external-secrets.io/guides-templating/) or the sealed secrets controller (see https://github.com/bitnami-labs/sealed-secrets/blob/main/docs/examples/config-template/sealedsecret.yaml for an example)

This would allow consumers of secrets complete control over how the service key gets transformed to a Kubernetes secret and would therefore allow complete adaption into any kind of consumption use case.

It seems to be common practice to allow only templating of secret values (not keys), this restricts the possibilities a little but should be sufficient for most/all applications.

Hi colleagues,

we noticed that if a service binding (e.g. identity service) has a property that is an array (e.g. domains), the property will be "flattened" into a single file.

E.g. Identity Service binding on CF:

"credentials": {
            .....
            "domains": [
                "accounts400.ondemand.com"
             ]
}

on K8s we have a file domains containing:

["accounts400.ondemand.com"]

This poses a problem. Because in the “flattened” version applications need to "know" which fields are arrays. An application can’t just assume any value wrapped in [ … ] will be an array, it might also just be part of the value. E.g. a client secret.

For applications, this is at least inconvenient. For libraries & tools, that support various services, it's a slightly bigger problem. Do you think this could be improved in the future?

Kind regards,
Matthias

Hello operator team,

I was trying to use the operator, but after installing the helm chart (with no errors) and applying the following yaml:

apiVersion: services.cloud.sap.com/v1alpha1
kind: ServiceInstance
metadata:
    name: operator-destination-service
spec:
    serviceOfferingName: destination
    servicePlanName: lite

I receive the following error when reading the logs of the service:

error: no kind "ServiceInstance" is registered for version "services.cloud.sap.com/v1alpha1" in scheme "k8s.io/kubectl/pkg/scheme/scheme.go:28"

I believed I followed all the steps mentioned in the setup, what am I missing?

Hi there,

I have a golang application that consumes multiple BTP, runs on CF and which I would like to deploy to K8s as well.
To read in all the binding credentials I have structs that I unmarshal into from VCAP_SERVICES, something like

type myService struct{
  key1 string
  key2 otherType
}
var x myServices
.. json.Unmarshal(.., &x) ...

The way the service operator creates K8s secrets makes it hard to populate structs with service credentials.
It's possible to use either

• env variables, where I have to assign each env variable to the correct struct field
• files, where one file per credential key is created. It's possible to create a map with one key per file, unmarshal the file content, marshal to string, unmarshal to struct. This is doable but somewhat cumbersome.

Therefore my question(s):
What is the recommended way to unmarshal service credentials into golang structs?
Is there perhaps a library that you use (internally)? Have you already thought about creating secrets that contain one key only so unmarshaling is simplified?

Thanks and best regards!

Currently, the sap-btp-operator requires a lot of cluster-wide permissions (https://github.com/SAP/sap-btp-service-operator/blob/main/config/rbac/role.yaml).

We should narrow this down to the namespaces that the sap-btp-operator is watching.

Hi colleagues,

do you publish the helm chart for BTP service operator to any publicly or internally available helm chart repository, or do you plan to do so?

Helm Chart repositories are useful when installing several Charts into a cluster. For example a Chart can become a dependency of another chart only if it is available via a helm chart repository.

When set allowPrivilegedContainers to false, the deployment will fail to start.

NAME                                                  READY   STATUS                       RESTARTS   AGE
sap-btp-operator-controller-manager-fc9464c56-628w6   1/2     CreateContainerConfigError   0          11m

The pod information is:

Events:
  Type     Reason       Age                  From                                                         Message
  ----     ------       ----                 ----                                                         -------
  Normal   Scheduled    <unknown>                                                                         Successfully assigned sap-btp-operator/sap-btp-operator-controller-manager-fc9464c56-628w6 to shoot--cloudcitst--em1-worker-l161d-z2-8457f-b425p
  Warning  FailedMount  11m (x6 over 12m)    kubelet, shoot--cloudcitst--em1-worker-l161d-z2-8457f-b425p  MountVolume.SetUp failed for volume "cert" : secret "webhook-server-cert" not found
  Normal   Pulling      11m                  kubelet, shoot--cloudcitst--em1-worker-l161d-z2-8457f-b425p  Pulling image "ghcr.io/sap/sap-btp-service-operator/controller:v0.1.14"
  Normal   Pulled       11m                  kubelet, shoot--cloudcitst--em1-worker-l161d-z2-8457f-b425p  Successfully pulled image "ghcr.io/sap/sap-btp-service-operator/controller:v0.1.14" in 5.37466058s
  Normal   Created      11m                  kubelet, shoot--cloudcitst--em1-worker-l161d-z2-8457f-b425p  Created container manager
  Normal   Started      11m                  kubelet, shoot--cloudcitst--em1-worker-l161d-z2-8457f-b425p  Started container manager
  Warning  Failed       10m (x7 over 11m)    kubelet, shoot--cloudcitst--em1-worker-l161d-z2-8457f-b425p  Error: container has runAsNonRoot and image will run as root (pod: "sap-btp-operator-controller-manager-fc9464c56-628w6_sap-btp-operator(ac9d0ac0-960f-4c5f-aa93-e23ef3b98a18)", container: kube-rbac-proxy)
  Normal   Pulled       2m2s (x47 over 11m)  kubelet, shoot--cloudcitst--em1-worker-l161d-z2-8457f-b425p  Container image "gcr.io/kubebuilder/kube-rbac-proxy:v0.5.0" already present on machine

Hello,

there are some services that require a re-bind after a certain time period to update the service credentials (e.g. for renewing certs).
Does the operator support a mechanism (e.g. via an annotation) to trigger such a re-bind?

In theory, it is possible to create a second binding with a different name, but this would require changing the deployment yaml on each update. That's why it would be much more convenient to have an annotation or similar.
Thank you!

Currently the kubectl plugin does not work when mTLS credentials are provided.

It would be nice to support that as well.

Remark: currently the plugin directly retrieves and uses the credentials used by the operator, this creates an intresting security model (=> users of the plugin need to be admins of the operator as well, operator operates cluster wide by default, users might only have access to specific namespaces) - maybe an alternative solution could be found where users talk to the operator instead

Hi colleagues,

we noticed that upon creating a service binding (e.g. for XSUAA, IAS or Destination Service) the Service Operator "only" provides the credentials as Kubernetes secret.

However, some existing libraries and applications rely on other information that is usually available in the service binding. For example, the Java Security Library requires the service plan to be available for IAS or XSUAA bindings. Other services may provide other information outside of the service credentials, e.g. different endpoints for read/write, settings etc.

Q: Will the Service Operator provision such values in the future? If not, how should applications obtain the required information?

Thanks in advance!