Add CNB Service Bindings to Image and Build resources #371
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The CNB Service Bindings spec provides a structured way to expose
service metadata and credentials into a build. For example, the build
can use the binding information to install a database driver, configure
an APM agent for the built image, or discover any other capability
outside of the built container.
Each binding reference has a name, a reference to a k8s ConfigMap
holding service metadata, and optionally a k8s Secret holding service
credentials. Builds generally should not have access to the credentials
so that the values are not backed into the built image, but instead
bound fresh at runtime.
For images, the bindings are located at `.spec.build.bindings`:
```
kind: Image
...
spec:
...
build:
bindings:
- name: my-binding
metadataRef:
name: provider-binding-metadata
secretRef:
name: provider-binding-secret
```
For builds, the bindings are located at `.spec.bindings`:
```
kind: Build
...
spec:
...
bindings:
- name: my-binding
metadataRef:
name: provider-binding-metadata
secretRef:
name: provider-binding-secret
```
In the build the bindings appear as a directory tree under the path
specified by the `$CNB_BINDINGS` env var. Each binding is a directory,
which in turn has a `metadata` directory with files and if credentials
are exposed a `secret` directory with more files. The environment
variable and volume mounts are available during the detect and build
steps. Currently, the value of `$CNB_BINDINGS` is `/var/bindings` but
should not be presumed to be stable or consistent with the value at
runtime.
There is no guarantee the same services, or types of services, will be
bound at runtime.
Refs buildpacks-community#369
djoyahoy
approved these changes
May 4, 2020
matthewmcnew
reviewed
May 5, 2020
Codecov Report
@@ Coverage Diff @@
## master #371 +/- ##
==========================================
+ Coverage 67.52% 68.26% +0.73%
==========================================
Files 81 81
Lines 3307 3409 +102
==========================================
+ Hits 2233 2327 +94
- Misses 800 805 +5
- Partials 274 277 +3
Continue to review full report at Codecov.
|
thisisnotashwin
approved these changes
May 6, 2020
There are questions that need to be further explored about the implications of supporting secret binding. Exposing the secret name would potentially expose an enumeration attack again other secrets in the namespace.
|
Used the validator to disable the secretRef on the binding until we have a better understanding of how to protect again secret enumeration attacks, or direct capturing of secrets if they know the name. |
This reverts commit 990504f.
|
Based on our conversation yesterday, I switch up the secret handling to forbid binding secrets that are attached to any service account in the namespace. This should offer a reasonable compromise to protect registry, and api server credentials while still allowing bindings to work as expected. Users who need more fine grain restrictions should look at applying a policy engine like OPA to make those access decisions. |
thisisnotashwin
approved these changes
May 8, 2020
| namespace: namespace, | ||
| bindings: []v1alpha1.Binding{ | ||
| { | ||
| Name: "naughty", |
| @@ -0,0 +1,64 @@ | |||
| apiVersion: build.pivotal.io/v1alpha1 | |||
pkg/apis/build/v1alpha1/build_pod.go
Outdated
| @@ -110,6 +110,51 @@ func (b *Build) BuildPod(config BuildPodImages, secrets []corev1.Secret, bc Buil | |||
| SubPath: b.Spec.Source.SubPath, // empty string is a nop | |||
| } | |||
|
|
|||
| bindingVolumes := []corev1.Volume{} | |||
There was a problem hiding this comment.
can this be moved into a private method setupBindings()?
matthewmcnew
approved these changes
May 11, 2020
matthewmcnew
added a commit
that referenced
this pull request
May 12, 2020
- #371 will list all service accounts on build create
matthewmcnew
added a commit
that referenced
this pull request
May 12, 2020
- #371 will list all service accounts on build create
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The CNB Service Bindings spec provides a structured way to expose
service metadata and credentials into a build. For example, the build
can use the binding information to install a database driver, configure
an APM agent for the built image, or discover any other capability
outside of the built container.
Each binding reference has a name, a reference to a k8s ConfigMap
holding service metadata, and optionally a k8s Secret holding service
credentials. Builds generally should not have access to the credentials
so that the values are not backed into the built image, but instead
bound fresh at runtime.
For images, the bindings are located at
.spec.build.bindings:For builds, the bindings are located at
.spec.bindings:In the build the bindings appear as a directory tree under the path
specified by the
$CNB_BINDINGSenv var. Each binding is a directory,which in turn has a
metadatadirectory with files and if credentialsare exposed a
secretdirectory with more files. The environmentvariable and volume mounts are available during the detect and build
steps. Currently, the value of
$CNB_BINDINGSis/var/bindingsbutshould not be presumed to be stable or consistent with the value at
runtime.
There is no guarantee the same services, or types of services, will be
bound at runtime.
Refs #369