vmware-tanzu / servicebinding Goto Github PK

View Code? Open in Web Editor NEW

31.0 6.0 20.0 7.3 MB

Service Bindings for Kubernetes

License: Other

Go 98.55% Shell 1.45%

servicebinding's Introduction

Service Bindings for Kubernetes

Service Bindings for Kubernetes implements the Service Binding Specification for Kubernetes v1.0.

This implementation provides support for:

The following are not implemented:

Workload Resource Mapping
Extensions including:
- Binding Secret Generation Strategies

Equivalent capabilities from the v1.0.0-rc3 (servicebinding.io/v1alpha3) version of the spec are also supported. There are no significant API or runtime changes between v1alpha3 and v1beta1 versions.

Try it out

Prerequisites:

a Kubernetes 1.18+ cluster

Using the latest release is recommended.

Build from source

We use Golang and ko to build the CRD and reconciler, and kapp to deploy them.

From within the cloned directory for this project, run:

kapp deploy -a service-bindings -f <(ko resolve -f config)

Uninstall

kapp delete -a service-bindings

Collecting logs from service binding manager

Retrieve pod logs from the manager running in the service-bindings namespace.

kubectl -n service-bindings logs -l role=manager

For example:

2021/11/05 15:25:28 Registering 3 clients
2021/11/05 15:25:28 Registering 3 informer factories
2021/11/05 15:25:28 Registering 7 informers
2021/11/05 15:25:28 Registering 8 controllers
{"severity":"INFO","timestamp":"2021-11-05T15:25:28.483823208Z","caller":"logging/config.go:116","message":"Successfully created the logger."}
{"severity":"INFO","timestamp":"2021-11-05T15:25:28.48392361Z","caller":"logging/config.go:117","message":"Logging level set to: info"}
{"severity":"INFO","timestamp":"2021-11-05T15:25:28.483999911Z","caller":"logging/config.go:79","message":"Fetch GitHub commit ID from kodata failed","error":"open /var/run/ko/HEAD: no such file or directory"}
{"severity":"INFO","timestamp":"2021-11-05T15:25:28.484035711Z","logger":"webhook","caller":"profiling/server.go:64","message":"Profiling enabled: false"}
{"severity":"INFO","timestamp":"2021-11-05T15:25:28.522884909Z","logger":"webhook","caller":"leaderelection/context.go:46","message":"Running with Standard leader election"}
{"severity":"INFO","timestamp":"2021-11-05T15:25:28.523358615Z","logger":"webhook","caller":"provisionedservice/controller.go:31","message":"Setting up event handlers."}
...
  {"severity":"ERROR","timestamp":"2021-11-17T15:00:24.561881861Z","logger":"webhook","caller":"controller/controller.go:548","message":"Reconcile error","duration":"167.902µs","error":"deployments.apps \"spring-petclinic\" not found","stacktrace":"knative.dev/pkg/controller.(*Impl).handleErr\n\tknative.dev/[email protected]/controller/controller.go:548\nknative.dev/pkg/controller.(*Impl).processNextWorkItem\n\tknative.dev/[email protected]/controller/controller.go:531\nknative.dev/pkg/controller.(*Impl).RunContext.func3\n\tknative.dev/[email protected]/controller/controller.go:468"}

Troubleshooting

For basic troubleshooting Service Bindings, please see the troubleshooting guide here.

Samples

Samples are located in the samples directory, including:

Resources

ServiceBinding (servicebinding.io/v1beta1)

The ServiceBinding resource shape and behavior is defined by the spec.

apiVersion: servicebinding.io/v1beta1
kind: ServiceBinding
metadata:
  name: account-db
spec:
  service:
    apiVersion: bindings.labs.vmware.com/v1alpha1
    kind: ProvisionedService
    name: account-db
  workload:
    apiVersion: apps/v1
    kind: Deployment
    name: account-service

ProvisionedService (bindings.labs.vmware.com/v1alpha1)

The ProvisionedService exposes a resource Secret by implementing the upstream Provisioned Service duck type, and may be the target of the .spec.service reference for a ServiceBinding. It is intended for compatibility with existing services that do not directly implement the duck type.

For example to expose a service with an existing Secret named account-db-service:

apiVersion: bindings.labs.vmware.com/v1alpha1
kind: ProvisionedService
metadata:
  name: account-db
spec:
  binding:
    name: account-db-service

---
apiVersion: v1
kind: Secret
metadata:
  name: account-db-service
type: Opaque
stringData:
  type: mysql
  # use appropriate values
  host: localhost
  database: default
  password: ""
  port: "3306"
  username: root

The controller writes the resource's status to implement the duck type.

Contributing

The Service Bindings for Kubernetes project team welcomes contributions from the community. If you wish to contribute code and you have not signed our contributor license agreement (CLA), our bot will update the issue when you open a Pull Request. For any questions about the CLA process, please refer to our FAQ. For more detailed information, refer to CONTRIBUTING.md.

Acknowledgements

Service Bindings for Kubernetes is an implementation of the Service Binding Specification for Kubernetes. Thanks to Arthur De Magalhaes and Ben Hale for leading the spec effort.

The initial implementation was conceived in projectriff/bindings by Scott Andrews, Emily Casey and the riff community at large, drawing inspiration from mattmoor/bindings and Knative duck type reconcilers.

License

Apache License v2.0: see LICENSE for details.

servicebinding's People

Contributors

Stargazers

Watchers

Forkers

markfisher scothis bartsmykla-test navidsh ilayaperumalg rosenhouse ekmixon danfein shashwathi odinnordico gabrielecipriano rashedkvm samze tzolov rohitagg2020 shaheerkootteeri anibmurthy chunyilyu

servicebinding's Issues

ServiceBinding reconciliation fails on kubernetes v1.22+

Bug description
ServiceBinding reconciliation fails on kubernetes v1.22.0+, the workload is not updated to mount the credentials from the service.

For context this was initially found as part of acceptance tests, but for ease of reproduction I have reproduced it using the spring-petclinic sample.

I have verified that this is not an issue for kubernetes v1.21.9.

Expected behavior
The reconciliation of the ServiceBinding succeeds, the workload Deployment is updated with a new environment variable (SERVICE_BINDING_ROOT), volume and volume mount, and the ServiceBinding status is populated.

Steps to reproduce the bug

Apply the spring-petclinic sample
kubectl get servicebindings.servicebinding.io spring-petclinic-db -o yaml and note that the status has not been populated
kubectl describe deployment.apps spring-petclinic -o yaml and note that the fields that were expected to have been populated detailed above have not been
kubectl logs -n service-bindings manager-... and note the reconciliation errors being reported

Version (Tanzu Application Platform version, K8s version)
kubernetes version: v.1.22.0, v.1.22.6, v1.23.1
(installed directly) service-bindings version: v0.5.0, v0.6.0
(or, installed via TAP) TAP version: v1.0.0

Environment where the bug was observed (cloud, OS, etc)
OS: Darwin v12.2
kubernetes distributions: minikube v1.25.1, kind v0.11.1

Relevant Debug Output (Logs, etc)

$ kubectl logs -n service-bindings manager-...
...
{"severity":"WARNING","timestamp":"2022-02-11T14:39:11.2667576Z","logger":"webhook","caller":"reconciler/reconcile_common.go:74","message":"A reconciliation included no top-level condition","knative.dev/controller":"github.com.vmware-labs.service-bindings.pkg.reconciler.servicebinding.Reconciler","knative.dev/kind":"servicebinding.io.ServiceBinding","knative.dev/traceid":"399a6b93-be8f-4b96-a3e1-580b0a0bd0ed","knative.dev/key":"default/spring-petclinic-db"}
{"severity":"INFO","timestamp":"2022-02-11T14:39:11.2744133Z","logger":"webhook","caller":"webhook/admission.go:89","message":"Webhook ServeHTTP request=&http.Request{Method:\"POST\", URL:(*url.URL)(0xc000d78ea0), Proto:\"HTTP/1.1\", ProtoMajor:1, ProtoMinor:1, Header:http.Header{\"Accept\":[]string{\"application/json, */*\"}, \"Accept-Encoding\":[]string{\"gzip\"}, \"Content-Length\":[]string{\"4011\"}, \"Content-Type\":[]string{\"application/json\"}, \"User-Agent\":[]string{\"kube-apiserver-admission\"}}, Body:(*http.body)(0xc000d57000), GetBody:(func() (io.ReadCloser, error))(nil), ContentLength:4011, TransferEncoding:[]string(nil), Close:false, Host:\"webhook.service-bindings.svc:443\", Form:url.Values(nil), PostForm:url.Values(nil), MultipartForm:(*multipart.Form)(nil), Trailer:http.Header(nil), RemoteAddr:\"10.244.0.1:38530\", RequestURI:\"/defaulting?timeout=10s\", TLS:(*tls.ConnectionState)(0xc00073cbb0), Cancel:(<-chan struct {})(nil), Response:(*http.Response)(nil), ctx:(*context.cancelCtx)(0xc000d57040)}"}
{"severity":"INFO","timestamp":"2022-02-11T14:39:11.2750515Z","logger":"webhook","caller":"webhook/admission.go:131","message":"remote admission controller audit annotations=map[string]string(nil)","knative.dev/kind":"servicebinding.io/v1alpha3, Kind=ServiceBinding","knative.dev/namespace":"default","knative.dev/name":"spring-petclinic-db","knative.dev/operation":"UPDATE","knative.dev/resource":"servicebinding.io/v1alpha3, Resource=servicebindings","knative.dev/subresource":"status","knative.dev/userinfo":"{system:serviceaccount:service-bindings:controller 441f0b75-d533-4e4e-8b37-daf6dae1868d [system:serviceaccounts system:serviceaccounts:service-bindings system:authenticated] map[authentication.kubernetes.io/pod-name:[manager-6fd9b58fc8-dlhgk] authentication.kubernetes.io/pod-uid:[8f9e0fe5-d78a-46a9-9705-42e31d5b976a]]}","admissionreview/uid":"e9d7b5ba-90f5-4bb3-86d2-237daf59c45a","admissionreview/allowed":false,"admissionreview/result":"&Status{ListMeta:ListMeta{SelfLink:,ResourceVersion:,Continue:,RemainingItemCount:nil,},Status:Failure,Message:mutation failed: cannot decode incoming new object: json: unknown field \"subresource\",Reason:BadRequest,Details:nil,Code:400,}"}
{"severity":"INFO","timestamp":"2022-02-11T14:39:11.2805507Z","logger":"webhook","caller":"webhook/admission.go:89","message":"Webhook ServeHTTP request=&http.Request{Method:\"POST\", URL:(*url.URL)(0xc000b63950), Proto:\"HTTP/1.1\", ProtoMajor:1, ProtoMinor:1, Header:http.Header{\"Accept\":[]string{\"application/json, */*\"}, \"Accept-Encoding\":[]string{\"gzip\"}, \"Content-Length\":[]string{\"4011\"}, \"Content-Type\":[]string{\"application/json\"}, \"User-Agent\":[]string{\"kube-apiserver-admission\"}}, Body:(*http.body)(0xc000b377c0), GetBody:(func() (io.ReadCloser, error))(nil), ContentLength:4011, TransferEncoding:[]string(nil), Close:false, Host:\"webhook.service-bindings.svc:443\", Form:url.Values(nil), PostForm:url.Values(nil), MultipartForm:(*multipart.Form)(nil), Trailer:http.Header(nil), RemoteAddr:\"10.244.0.1:38530\", RequestURI:\"/defaulting?timeout=10s\", TLS:(*tls.ConnectionState)(0xc00073cbb0), Cancel:(<-chan struct {})(nil), Response:(*http.Response)(nil), ctx:(*context.cancelCtx)(0xc000b37800)}"}
{"severity":"INFO","timestamp":"2022-02-11T14:39:11.2810255Z","logger":"webhook","caller":"webhook/admission.go:131","message":"remote admission controller audit annotations=map[string]string(nil)","knative.dev/kind":"servicebinding.io/v1alpha3, Kind=ServiceBinding","knative.dev/namespace":"default","knative.dev/name":"spring-petclinic-db","knative.dev/operation":"UPDATE","knative.dev/resource":"servicebinding.io/v1alpha3, Resource=servicebindings","knative.dev/subresource":"status","knative.dev/userinfo":"{system:serviceaccount:service-bindings:controller 441f0b75-d533-4e4e-8b37-daf6dae1868d [system:serviceaccounts system:serviceaccounts:service-bindings system:authenticated] map[authentication.kubernetes.io/pod-name:[manager-6fd9b58fc8-dlhgk] authentication.kubernetes.io/pod-uid:[8f9e0fe5-d78a-46a9-9705-42e31d5b976a]]}","admissionreview/uid":"aa96fc94-77f4-478c-b47f-995e7e3f4a49","admissionreview/allowed":false,"admissionreview/result":"&Status{ListMeta:ListMeta{SelfLink:,ResourceVersion:,Continue:,RemainingItemCount:nil,},Status:Failure,Message:mutation failed: cannot decode incoming new object: json: unknown field \"subresource\",Reason:BadRequest,Details:nil,Code:400,}"}
{"severity":"WARNING","timestamp":"2022-02-11T14:39:11.2830984Z","logger":"webhook","caller":"servicebinding/reconciler.go:270","message":"Failed to update resource status","knative.dev/controller":"github.com.vmware-labs.service-bindings.pkg.reconciler.servicebinding.Reconciler","knative.dev/kind":"servicebinding.io.ServiceBinding","knative.dev/traceid":"399a6b93-be8f-4b96-a3e1-580b0a0bd0ed","knative.dev/key":"default/spring-petclinic-db","targetMethod":"ReconcileKind","error":"admission webhook \"defaulting.webhook.bindings.labs.vmware.com\" denied the request: mutation failed: cannot decode incoming new object: json: unknown field \"subresource\""}
{"severity":"ERROR","timestamp":"2022-02-11T14:39:11.2832354Z","logger":"webhook","caller":"controller/controller.go:548","message":"Reconcile error","knative.dev/controller":"github.com.vmware-labs.service-bindings.pkg.reconciler.servicebinding.Reconciler","knative.dev/kind":"servicebinding.io.ServiceBinding","duration":"16.7685ms","error":"admission webhook \"defaulting.webhook.bindings.labs.vmware.com\" denied the request: mutation failed: cannot decode incoming new object: json: unknown field \"subresource\"","stacktrace":"knative.dev/pkg/controller.(*Impl).handleErr\n\tknative.dev/[email protected]/controller/controller.go:548\nknative.dev/pkg/controller.(*Impl).processNextWorkItem\n\tknative.dev/[email protected]/controller/controller.go:531\nknative.dev/pkg/controller.(*Impl).RunContext.func3\n\tknative.dev/[email protected]/controller/controller.go:468"}
{"severity":"INFO","timestamp":"2022-02-11T14:39:11.2837626Z","logger":"webhook.event-broadcaster","caller":"record/event.go:282","message":"Event(v1.ObjectReference{Kind:\"ServiceBinding\", Namespace:\"default\", Name:\"spring-petclinic-db\", UID:\"a0a38964-c043-4f88-afd2-706de3de497e\", APIVersion:\"servicebinding.io/v1alpha3\", ResourceVersion:\"31890\", FieldPath:\"\"}): type: 'Warning' reason: 'UpdateFailed' Failed to update status for \"spring-petclinic-db\": admission webhook \"defaulting.webhook.bindings.labs.vmware.com\" denied the request: mutation failed: cannot decode incoming new object: json: unknown field \"subresource\""}

ServiceBinding controller should not use servicebinding.io/controller: "true" for non-provisioned service rbac

Bug description

The ServiceBinding controller currently relies on the spec ClusterRole label servicebinding.io/controller: "true" to aggregate non-provisionedservice RBAC to the controller manager. See deployed config here.

The means any system that also aggregates on servicebinding.io/controller: "true" will pick up the internal RBAC for this controller. This also includes write permissions such as create/delete/update.

Expected behavior

That servicebinding.io/controller: "true" is only used for ProvisionedService types and should only contain get/list/watch.

Rename `service.binding/v1alpha2` to `servicebinding.io/v1alpha3`

This is mostly a straight rename, as we have disowned backwards compatibility until the spec is more stable. From this point forward the spec should be more stable.

The one place where we should preserve compatibility is in the aggregated cluster role. We should continue to support the previous label selector in addition to the new value.

Refs servicebinding/spec#185

Track test coverage

The unit test coverage of this project is rather poor at the moment. We should use a tool like codecov to track test coverage over time.

Support CRD v1beta1 APIs while major k8s distros continue to support them

Major k8s vendors continue to support pre-1.16 k8s versions which include the CRD v1beta APIs. Consider waiting to move to the CRD v1 APIs until pre-1.16 k8s versions are no longer supported by major vendors. See #40.

Support imagePullSecrets with the bundle

Put samples into a nonstandard folder or don't include them in the release bundle

I was consuming the latest release bundle and it still has the samples folder, this can be innocuous on a cluster that already has knative serving installed, but thankfully it errored out since I don't have all the necessary prerequisite CRDs.

.
├── LICENSE
├── NOTICE
├── samples
│   ├── controlled-resource
│   │   ├── application.yaml
│   │   ├── README.md
│   │   ├── service-binding.yaml
│   │   └── service.yaml
│   ├── multi-binding
│   │   ├── application.yaml
│   │   ├── README.md
│   │   ├── service-binding.yaml
│   │   └── service.yaml
│   ├── overridden-type-provider
│   │   ├── application.yaml
│   │   ├── README.md
│   │   ├── service-binding.yaml
│   │   └── service.yaml
│   ├── provisioned-service
│   │   ├── application.yaml
│   │   ├── README.md
│   │   ├── service-binding.yaml
│   │   └── service.yaml
│   └── spring-petclinic
│       ├── application.yaml
│       ├── README.md
│       ├── service-binding.yaml
│       └── service.yaml
├── service-bindings.yaml
└── VERSION

Suggest either moving service-bindings.yaml into a config folder (this is what a lot of other packages are doing), or just delete the sample folder entirely.

ServiceBinding always says a Secret is available/ready even if Secret isnt present

Bug description

When I create ServiceBinding where:

the workload is a Pod that exists
I've provided the correct RBAC for reading service
the service is a Secret that doesn't exist

I get Ready=True

Expected behaviour

I getReady=False, the service does not exist.

Steps to reproduce the bug

$ kubectl run nginx --image=nginx --restart=Never

$ kapply() { kaf <(echo "$1") } # func for convenience

$ kapply '# iterate-stk-secret-reader.yaml
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: stk-secret-reader
  labels:
    servicebinding.io/controller: "true"
rules:
- apiGroups: [""]
  resources: ["secrets", "pods" ]
  verbs: ["get", "list", "watch"]'

$ kapply 'apiVersion: servicebinding.io/v1beta1
kind: ServiceBinding
metadata:
  name: test-sb
spec:
  name: database
  service:
    apiVersion: v1
    kind: Secret
    name: test
  workload:
    apiVersion: v1
    kind: Pod
    name: nginx'

$ kubectl get secrets        
No resources found in default namespace.

$ kubectl get servicebinding         
NAME      READY   REASON   AGE
test-sb   True    Ready    6m55s

**Version (Tanzu Application Platform version, K8s version) **

Definitely in 0.7.2 of this, unsure what versions are affecred.

Environment where the bug was observed (cloud, OS, etc)

I observed it in Kind

ServiceBinding ready status condition does not transition to False when referenced service gets deleted

Bug description

I think I’ve found a potential bug (testing on v0.7.2) regarding the READY status of a ServiceBinding resource when the ProvisionedService referred to at .spec.service gets deleted

Expected behavior

I would expect that if the service referred to at .spec.service gets deleted, that the ServiceBinding would transition into READY=False, however it doesn’t, it remains at READY=True.

Steps to reproduce the bug

$ kubectl apply -f samples/provisioned-service/
$ kubectl get servicebinding provisioned-service
NAME                  READY   REASON   AGE
provisioned-service   True    Ready    93s
$ kubectl delete provisionedservice provisioned-service
$ kubectl get servicebinding provisioned-service
NAME                  READY   REASON   AGE
provisioned-service   True    Ready    3m3s                 # expected to be READY=False?

Version (Tanzu Application Platform verision, K8s version)

TAP 1.2 / k8s 1.23

Environment where the bug was observed (cloud, OS, etc)

On a kind cluster

Relevant Debug Output (Logs, etc)

{"level":"error","ts":"2022-08-22T08:36:43.454497946Z","logger":"webhook","caller":"servicebinding/reconciler.go:291","msg":"Returned an error","knative.dev/controller":"github.com.vmware-tanzu.servicebinding.pkg.reconcile
r.servicebinding.Reconciler","knative.dev/kind":"servicebinding.io.ServiceBinding","knative.dev/traceid":"4362a5e0-56b8-4e43-84f2-6160479a29cc","knative.dev/key":"sb-testing/provisioned-service","targetMethod":"ReconcileKind","error":"failed to get resour
ce for bindings.labs.vmware.com/v1alpha1, Resource=provisionedservices: provisionedservices.bindings.labs.vmware.com \"provisioned-service\" not found","stacktrace":"github.com/vmware-tanzu/servicebinding/pkg/client/injection/reconciler/servicebinding/v1a
lpha3/servicebinding.(*reconcilerImpl).Reconcile\n\tgithub.com/vmware-tanzu/servicebinding/pkg/client/injection/reconciler/servicebinding/v1alpha3/servicebinding/reconciler.go:291\nknative.dev/pkg/controller.(*Impl).processNextWorkItem\n\tknative.dev/pkg@
v0.0.0-20210902173607-983897f9e37f/controller/controller.go:530\nknative.dev/pkg/controller.(*Impl).RunContext.func3\n\tknative.dev/[email protected]/controller/controller.go:468"}
{"level":"error","ts":"2022-08-22T08:36:43.454560685Z","logger":"webhook","caller":"controller/controller.go:548","msg":"Reconcile error","knative.dev/controller":"github.com.vmware-tanzu.servicebinding.pkg.reconciler.serv
icebinding.Reconciler","knative.dev/kind":"servicebinding.io.ServiceBinding","duration":0.000317159,"error":"failed to get resource for bindings.labs.vmware.com/v1alpha1, Resource=provisionedservices: provisionedservices.bindings.labs.vmware.com \"provisi
oned-service\" not found","stacktrace":"knative.dev/pkg/controller.(*Impl).handleErr\n\tknative.dev/[email protected]/controller/controller.go:548\nknative.dev/pkg/controller.(*Impl).processNextWorkItem\n\tknative.dev/[email protected]
902173607-983897f9e37f/controller/controller.go:531\nknative.dev/pkg/controller.(*Impl).RunContext.func3\n\tknative.dev/[email protected]/controller/controller.go:468"}
{"level":"info","ts":"2022-08-22T08:36:43.455023028Z","logger":"webhook.event-broadcaster","caller":"record/event.go:282","msg":"Event(v1.ObjectReference{Kind:\"ServiceBinding\", Namespace:\"sb-testing\", Name:\"provisione
d-service\", UID:\"1eda0046-ed38-432a-9c18-d5bf9cbbf68b\", APIVersion:\"servicebinding.io/v1alpha3\", ResourceVersion:\"91998317\", FieldPath:\"\"}): type: 'Warning' reason: 'InternalError' failed to get resource for bindings.labs.vmware.com/v1alpha1, Res
ource=provisionedservices: provisionedservices.bindings.labs.vmware.com \"provisioned-service\" not found"}

Merge prep and main servicebinding controllers

We currently have two controller for the service binding resource, this is fragile and can cause contention if both need to update the resource. By combining them into a single controller we can unify the reconciler lifecycle for the resource.

Reject ServiceBindings with duplicate env names

Environment variable must have a unique name. A ServiceBinding that defines two vars with the same name is inherently invalid.

Please tag release bundles with the released version

Hi, I downloaded the latest release (0.4.0):

$ imgpkg copy --tar service-bindings-bundle-0.4.0.tar --to-repo repo.example.com/imgpkg/bundles/service-bindings --lock-output current-version.yaml
copy | importing 2 images...

 32.52 MiB / 32.52 MiB [==================================================================================================================================================] 100.00% 59.24 MiB/s 0s

copy | done uploading images
Succeeded
$ cat current-version.yaml 
---
apiVersion: imgpkg.carvel.dev/v1alpha1
bundle:
  image: repo.example.com/imgpkg/bundles/service-bindings@sha256:9d79a03eeacfd01269f368f778ef9fcfab6f413cbf1293a43f39dc925bfc790a
  tag: latest
kind: BundleLock

I would love if this was tagged to 0.4.0 instead of latest

I think these two lines:
https://github.com/vmware-labs/service-bindings/blob/main/.github/workflows/ci.yaml#L88-L89

Just needs to change to include the current version in the tag, if that's at all possible.
So instead of:

imgpkg push -f "bundle" -b "${BUNDLE}"
imgpkg copy -b "${BUNDLE}" --to-tar bundle/service-bindings-bundle.tar

Have:

imgpkg push -f "bundle" -b "${BUNDLE}:${VERSION}"
imgpkg copy -b "${BUNDLE}:${VERSION}" --to-tar bundle/service-bindings-bundle.tar

Acceptance tests should not run if unit tests fail

Remove deprecated support for SERVICE_BINDINGS_ROOT

The var should be SERVICE_BINDING_ROOT. Currently we support both, but should drop support for the non-spec value.

Revert a07eb3c

Clean installs/uninstalls with kapp

kapp (https://get-kapp.io) is a tool to manage resources. Unlike kubectl, it will resolve dependencies between resources so that all of the resources are created/updated/removed in a single pass. For complex interdependencies, sometimes kapp will get the ordering wrong.

Because of the mutating webhooks and resource finalizers, a naive delete of the service bindings component may deadlock. We should add hints to kapp so that it is able to cleanly install, update and uninstall service bindings from a cluster.

Create acceptance tests

We should install service bindings into a real cluster (probably kind) and test bindings end to end.

Ensure unique volume names in application projection

The name of each volume in a pod must be unique. Since we are injecting into an existing pod template, we need to make sure each new volume has a unique name. The name has no semantic meaning other than it must be identical to the value used in a container's volume mount. The name should also be stable to avoid unnecessary mutations.

Generate the projected secret name

The projected secret is a new secret derived from the service's secret. We should take care to not collide with an existing secret, or another binding for the same service.

Infinite reconcile loop when injecting multiple service bindings into a single application

When creating 2 separate ServiceBinding resources with different service selectors but pointing to same application (regular Deployment) the deployment gets into infinite reconcile loop.

Each version of deployment has only info from one of ServiceBinding CRs and it keeps switching
It seems that mounted volumes order keeps changing as well as env keeps being added and removed and each version of Deployment

Reject ServiceBindings with duplicate mapping names

Mappings define a new key in the projected secret. As a secret can have a single value for a given key, defining multiple mappings with the same key should be rejected.

CI Release build failing

Bug description
CI Release build failing
Expected behavior
CI Release build passing
Steps to reproduce the bug
Commit a tag and CI release build will show failing
**Version (Tanzu Application Platform verision, K8s version) **
n/a
Environment where the bug was observed (cloud, OS, etc)
Github Actions
Relevant Debug Output (Logs, etc)

imgpkg copy --tar service-bindings-bundle.tar --to-repo "${repo}"


imgpkg: Error: Updating Image Refs registry.local:5000/service-bindings/bundle@sha256:8db097671917f25f32d5a7afe54f95a0c112728e024c9f80524d45b11438ea82:
Fetching images of registry.local:5000/service-bindings/bundle@sha256:8db097671917f25f32d5a7afe54f95a0c112728e024c9f80524d45b11438ea82:
    Fetching location image:
      Get "https://registry.local:5000/v2/": dial tcp: lookup registry.local on 127.0.0.53:53: server misbehaving; Get "http://registry.local:5000/v2/": dial tcp: lookup registry.local on 127.0.0.53:53: server misbehaving

Error: Process completed with exit code 1.

Standardize Log format timestamp

Describe the feature request
Standardize Log format timestamp with RFC 3339
Is your feature request related to a problem? Please describe

Describe alternatives you've considered

Additional context
Example

{"level":"info","ts":"2022-02-24T19:13:33.570546673Z","logger":"mycontroller","msg":"Pod status updated","pod":{"name":"nginx-1","namespace":"default"},"status":"ready"}

Update Go version to avoid CVEs

Describe the feature request

Some CVEs, recently published are related with golang version >= 1.19.6 , upgrading golang version these CVEs won't be a risk for this component

Is your feature request related to a problem? Please describe

Describe alternatives you've considered

Additional context

Remove support for custom projection

Custom projection is no longer an extension to the service binding spec. We can also drop support.

Mechanically, we'll likely need to keep the split between enriching the secret and projecting the binding into the application.

Cluster Role does not have access to Jobs

Bug description
TAP Service Binding package the service-binding-apps Cluster Role does not have access to Jobs (just Deployment, DS, and STS)

Expected behavior
service-bindings-app cluster role should include job
Steps to reproduce the bug

**Version (Tanzu Application Platform verision, K8s version) **
TAP 1.0.0 (service bindings)
Environment where the bug was observed (cloud, OS, etc)

Relevant Debug Output (Logs, etc)
https://github.com/vmware-labs/service-bindings/blob/main/samples/overridden-type-provider/workload.yaml#L6

Environment variables added multiple times

If someone or something removes internal.service.binding/projection-.... annotation from application resource (eg Deployment) environment variables are aded more then once in infinite reconcile loop.

Mutating webhook in a tight update loop

The servicebindingprojections.webhook.bindings.labs.vmware.com MutatingWebhookConfiguration is updated by the manager to intercept resources that are targeted by a binding. This update is currently in a tight loop appending the same chunk of config over and over. While it still functionally works (and our acceptance tests pass) the performance is terrible.

We can either wait for the upstream bug to be fixed, or change the labels we use for a namespace/object to opt-out of binding. If we adjust the label to include knative.dev we'd bypass the upstream bug.

Upstream knative/pkg#2110

Include information about min resource requirements on installation instructions (CPU, RAM, HDD, N/W)

Update ko base image and add k8s verion 1.27 to test matrix

Describe the request
There are new versions of Kubernetes (k8s) and the .ko base image available, which include updates to dependencies. It is advantageous to upgrade the version in servicebinding to ensure it remains up to date.

Is your feature request related to a problem? Please describe

Describe alternatives you've considered

Additional context

ServiceBindingProjection not created

Hi guys, great project!

I am trying to create a custom projection as so:

apiVersion: service.binding/v1alpha2
kind: ServiceBinding
metadata:
  annotations:
    projection.service.binding/type: Custom
  name: custom-projection
  namespace: service-binding
spec:
  application:
    apiVersion: v1
    kind: Deployment
    name: sample
  service:
    apiVersion: postgresql.baiju.dev/v1alpha1
    kind: Database
    name: db-demo

as described in the samples, using my own app and database. However no ServiceBindingProjection resource is created. The status of the ServiceBinding is updated:

  conditions:
  - lastTransitionTime: "2020-10-08T18:02:59Z"
    status: Unknown
    type: ProjectionReady
  - lastTransitionTime: "2020-10-08T18:02:59Z"
    message: unsuccessfully observed a new generation
    reason: NewObservedGenFailure
    status: Unknown
    type: Ready
  - lastTransitionTime: "2020-10-08T18:02:59Z"
    status: Unknown
    type: ServiceAvailable
  observedGeneration: 1

Manager pod logs

Event triggered by manager pod:

apiVersion: v1
count: 2
eventTime: null
firstTimestamp: "2020-10-08T18:02:59Z"
involvedObject:
  apiVersion: service.binding/v1alpha2
  kind: ServiceBinding
  name: custom-projection
  namespace: service-binding
  resourceVersion: "2742820"
  uid: 541b7bcd-8227-413c-b7ec-f975e93e33b1
kind: Event
lastTimestamp: "2020-10-08T18:02:59Z"
message: 'ServiceBinding reconciled: "service-binding/custom-projection"'
metadata:
  creationTimestamp: "2020-10-08T18:02:59Z"
  name: custom-projection.163c16627b7b87a9
  namespace: service-binding
  resourceVersion: "2742822"
  selfLink: /api/v1/namespaces/service-binding/events/custom-projection.163c16627b7b87a9
  uid: 7b68852a-1849-4dff-9414-2fa45db3c2ea
reason: Reconciled
reportingComponent: ""
reportingInstance: ""
source:
  component: servicebinding-controller
type: Normal

Thanks!

No error reporting when service is not matched

About

When creating a ServiceBinding resource with a .spec.service reference that cannot be resolved, the ServiceBinding resource does not set a failure condition and the controller does not include any useful error messages. This seems to happen if it cannot find the resource for any reason, e.g. an incorrect apiVerison/Kind/or Name. This makes it hard to debug the problem.

Looking at the controller logs this is the only error that appears, perhaps it's failing while trying to update the status?

{"severity":"ERROR","timestamp":"2021-09-16T16:38:57.735387879Z","logger":"webhook","caller":"controller/controller.go:548","message":"Reconcile error","knative.dev/controller":"github.com.vmware-labs.service-bindings.pkg.reconciler.servicebinding.Reconciler","knative.dev/kind":"servicebinding.io.ServiceBinding","duration":"12.506546ms","error":"ServiceBinding.servicebinding.io "rmq-binding" is invalid: [status.conditions.status: Unsupported value: "": supported values: "True", "False", "Unknown", status.conditions.lastTransitionTime: Invalid value: "null": status.conditions.lastTransitionTime in body must be of type string: "null", status.conditions.reason: Invalid value: "": status.conditions.reason in body should be at least 1 chars long]","stacktrace":"knative.dev/pkg/controller.(*Impl).handleErr\n\tknative.dev/[email protected]/controller/controller.go:548\nknative.dev/pkg/controller.(*Impl).processNextWorkItem\n\tknative.dev/[email protected]/controller/controller.go:531\nknative.dev/pkg/controller.(*Impl).RunContext.func3\n\tknative.dev/[email protected]/controller/controller.go:468"}

Using this release https://github.com/vmware-labs/service-bindings/releases/download/v0.5.0/service-bindings-0.5.0.yaml

To reproduce

Install 0.5.0 kapp deploy -a service-bindings -f https://github.com/vmware-labs/service-bindings/releases/download/v0.5.0/service-bindings-0.5.0.yaml
Install the RMQ operator kubectl apply -f https://github.com/rabbitmq/cluster-operator/releases/latest/download/cluster-operator.yml
Apply the following YAML - note we have not created the referenced RMQ.

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: service-binding-rmq
  labels:
    servicebinding.io/controller: "true"
rules:
- apiGroups: ["rabbitmq.com"]
  resources: ["rabbitmqclusters"]
  verbs: ["get", "list", "watch"]

---
apiVersion: servicebinding.io/v1alpha3
kind: ServiceBinding
metadata:
  name: rmq-binding
spec:
  service:
    apiVersion: rabbitmq.com/v1beta1
    kind: RabbitmqCluster
    name: hello-world
  workload:
    apiVersion: apps/v1
    kind: Deployment
    name: rmq-app

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: rmq-app
  labels:
    app: rmq-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: rmq-app
  template:
    metadata:
      labels:
        app: rmq-app
    spec:
      containers:
      - name: spring-rabbitmq-app
        image: ismteam/spring-rabbitmq-app:latest
        imagePullPolicy: IfNotPresent

Check the binding resource - verify you get no status updated and no updated conditions.

k get servicebinding
NAME          READY   REASON   AGE
rmq-binding                    3m45s

Add Grype Scanning

Describe the feature request
Add Grype Scanning
Is your feature request related to a problem? Please describe
Detect CVE
Describe alternatives you've considered

Additional context
Adding Grype Scanning in CI

ServiceBinding does not set to Ready=False or Unknown if the service is not a ProvisionedService

Bug description
Pointing ServiceBinding at a a service which isn't a ProvisionedService should lead to at least one condition according to the binding spec https://github.com/servicebinding/spec#ready-condition-status. At the moment there's no conditions.

It just sets to "" in my case.

Expected behavior

Set Ready=False or Ready=Unknown.

Steps to reproduce the bug

Create ServiceBinding (with appropriate read RBAC) and point it at a service that does not follow the binding spec.

**Version (Tanzu Application Platform verision, K8s version) **

Tried with latest 0.8.1 of binding spec

Environment where the bug was observed (cloud, OS, etc)

Any k8s.

Relevant Debug Output (Logs, etc)

Transparently apply multiple bindings via webhook

When a bound resource is created/updated, a mutating webhook intercepts that request and applies the binding to the target resource. This works when there is 0 or 1 binding targeting the resource, but is inconsistent when there are 2+ bindings targeting the same resource. The webhook will only apply one binding. The other bindings are applied by the controller after the mutation was persisted on the API Server.

While the resource will reach a level state, there are inconsistent transient states before settling. This creates unnecessary load on the API Server and can cause undefined behavior based on other controllers in the system interacting with that resource.

The root cause of this issue will need to be fixed upstream in knative/pkg.

Follow up to #66

Invitation/Proposal to collaborate on a single implementation

Hi @scothis @nebhale ,

I’m Shoubhik, a maintainer of redhat-developer/service-binding-operator . The project, kicked-off in June 2019 has evolved significantly since then based on the feedback we've received from our users.

Recently, it’s been proposed that we support k8s-service-bindings/spec in our project alongside our current implementation. The new implementation as far as I understand would be along the lines of vmware-labs/service-bindings based on k8s-service-bindings/spec .

Therefore, I was wondering if you would be interested in collaborating on a single implementation of Service Binding, instead of VMware and Red Hat working on their own ?

From a logistics standpoint, among other things, that would imply

A code repository for a Service Binding implementation for Kubernetes, in a neutral Github org
A governance where the founding contributors have an equal number of seats ( Red Hat: N, VMware: N , IBM: N, and Others who would want to join? ).
This could be expanded to follow a standard open source governance model with a plan to donate it to a foundation.

Details would need to be worked out for sure, but I wanted to check if this would be something you would want to consider. Let me know!

Best wishes,
Shoubhik

cc @arthurdm @pedjak

Service Resources with non-obvious pluralization fails

The service-binding controller uses this unsafe method to determine the GVR from the GVK to setup a watch dynamically. This method attempts to guess the GVR with some string checks and a lot of assumptions.

Unfortunately this Postgres Operator this fails inference of the pluralization. The plural is postgreses but just postgres.

This blocks this operator from being used with the binding operator. The only workaround is to use a direct secret reference.

cc @jpatel-pivotal

Note: Plural resource name for Postgres is postgres rather than the incorrect inferred postgreses

Replace deprecated `set-output` command with environment file

Describe the issue
In workflow, set-output command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information, see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

vmware-tanzu / servicebinding Goto Github PK

servicebinding's Introduction

Service Bindings for Kubernetes

Try it out

Build from source

Uninstall

Collecting logs from service binding manager

Troubleshooting

Samples

Resources

ServiceBinding (servicebinding.io/v1beta1)

ProvisionedService (bindings.labs.vmware.com/v1alpha1)

Contributing

Acknowledgements

License

servicebinding's People

Contributors

Stargazers

Watchers

Forkers

servicebinding's Issues

About

To reproduce

Recommend Projects

Recommend Topics

Recommend Org