diff --git a/enhancements/builds/volume-secrets.md b/enhancements/builds/volume-secrets.md
new file mode 100644
index 00000000000..1c3352fad48
--- /dev/null
+++ b/enhancements/builds/volume-secrets.md
@@ -0,0 +1,104 @@
+---
+title: volume-mounted-secret-and-configmap-injection
+authors:
+  - "@bparees"
+reviewers:
+  - @adambkaplan
+  - @smarterclayton
+approvers:
+  - @adambkaplan
+creation-date: 2020-01-08
+last-updated: 2020-01-08
+status: provisional
+---
+
+# Volume Mounted Secret+ConfigMap Injections
+
+
+## Release Signoff Checklist
+
+- [ ] Enhancement is `implementable`
+- [ ] Design details are appropriately documented from clear requirements
+- [ ] Test plan is defined
+- [ ] Graduation criteria for dev preview, tech preview, GA
+- [ ] User-facing documentation is created in [openshift-docs](https://github.com/openshift/openshift-docs/)
+
+## Open Questions [optional]
+
+ > 1. Can we make this the default or even only behavior for builds?  Probably not, need to make it opt-in to avoid potentially breaking existing buildconfigs.
+
+## Summary
+
+Today builds support getting source input from configmaps and secrets.  When users utilize this feature, the configmap or secret is volume-mounted into the build pod.  The next steps depend on whether it is an s2i or dockerfile build.
+
+For s2i builds, the generated Dockerfile contains commands to `ADD` the content at a path specified by the user, the assemble script is invoked, and then the injected content is zeroed out prior to committing the image via a `RUN rm` command added to the Dockerfile.
+
+For dockerfile builds, the user is instructed to add appropriate `ADD` and `RUN rm` commands to their dockerfile to inject the content that is available in the build's working directory (along with their application source, where applicable).
+
+There are a few undesirable aspects to this:
+1) In the dockerfile case, the content can still be found in lower layers of the image unless a layer squashing option is 
+selected.
+2) Requires extra work by the user in the Dockerfile, so each Dockerfile must be customized
+
+This enhancement proposes to use buildah's capability to mount a volume at build time.  The content mounted into the build pod would be then mounted into the container processing the Dockerfile, making that content available within the container so Dockerfile commands could reference it.  No explicit `ADD` would be required, and since mounted content is not committed to the resulting image, no `RUN rm` equivalent is required to clean up the injected content.
+
+
+## Motivation
+
+### Goals
+
+* Simplify how users consume secret + configmap content in builds
+* Increase the security of protected content being injected to images
+* Simplify use cases like mounting subscription entitlement credentials into a build so subscription content can be pulled down during a build while not including the credentials in the resulting image.
+
+### Non-Goals
+
+* This enhancement is not related to the frequently requested "build volumes" feature which would make it possible to mount a volume during a build and read/write content on that volume during the build such as to cache dependencies.
+
+
+## Proposal
+
+### User Stories [optional]
+
+The enabled use cases are essentially identical to what can be done with the configmap/secret input api in builds today, but with a better user experience and security as discussed above.  It does not enable a new use case that is not already possible today, except that layer squashing will not be required.
+
+### Implementation Details/Notes/Constraints [optional]
+
+We will need to introduce a new field in the build api which allows the user to indicate that they want to use this mechanism to inject their configmap/secret content, rather than the existing mechanism.
+
+The build pod will continue to mount the content as it already does, however the logic that generates the dockerfile(for s2i) and invokes buildah(for both dockerfile + s2i builds) will need to change to not augment the dockerfile, but instead to pass volume mount paths to buildah.  It will mount the content from the path it was mounted into the build pod, and mount it to the destination path provided by the user (the same path where the logic previously injected it via the dockerfile `ADD` command).
+
+
+### Risks and Mitigations
+
+## Design Details
+
+### Test Plan
+
+This feature will need new e2e tests that leverage the new api option.  We have existing tests for configmap+secret injection would should be able to be copied+adapted to testing this feature relatively easily.
+
+
+### Graduation Criteria
+
+This should be introduced directly as a GA feature when it is implemented.
+
+### Upgrade / Downgrade Strategy
+
+N/A
+
+### Version Skew Strategy
+
+N/A
+
+## Implementation History
+
+Major milestones in the life cycle of a proposal should be tracked in `Implementation
+History`.
+
+## Drawbacks
+
+Additional user complexity in choosing when to enable this behavior.  It is also unfortunate we can't default it because it will be a better choice for most users.
+
+## Alternatives
+
+N/A