Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tunnel: allow remote and API to accept --secrets #12414

Merged
merged 3 commits into from
Nov 30, 2021

Conversation

flouthoc
Copy link
Collaborator

@flouthoc flouthoc commented Nov 25, 2021

Following commit makes sure that build api can accept external
secret and allows currently NOOP podman-remote build -t tag --secret id=mysecret,src=/path/on/host to become functional.

TLDR:

Adds support for
podman-remote build -t tag --secret id=mysecret,src=/path/on/host .


Just like docker following api is a hidden field and only exposed to
podman-remote but could document it if it needs exposed on swagger.

Closes: #12415

@flouthoc
Copy link
Collaborator Author

Solves: #12415 (comment)

Copy link
Member

@vrothberg vrothberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[NO NEW TESTS NEEDED]

Please add tests. Skipping adding tests is something we must discourage, and I've reminded on multiple occasions that we must explain why if there is really no way to test a change.

Changes LGTM

@flouthoc
Copy link
Collaborator Author

flouthoc commented Nov 25, 2021

@vrothberg Sure I am just waiting for discussion to close on something will add tests as soon as this is ready to be merged. Marking this as draft for now. Since this still does not solves the actual problem.

@flouthoc flouthoc marked this pull request as draft November 25, 2021 12:19
@openshift-ci openshift-ci bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Nov 25, 2021
@flouthoc
Copy link
Collaborator Author

@vrothberg We could copy secrets over to remote VM but not sure if its the right thing to do. I think we should do a bind mount hence this would still not solve cases like podman-remote build -t tag --secret id=mysecret,src=/path/on/host .

@rhatdan
Copy link
Member

rhatdan commented Nov 26, 2021

It is the right thing to do, copy the secret to the remote machine, but destroy it when the container is removed. Secrets are secret to the container, IE they do not get committed to the image. They are not secrets between the client and server. You might want to clarify this in the man pages, but they need to be copied. Mounting will not work if you are actually using a remote system as opposed to a VM.

@flouthoc
Copy link
Collaborator Author

@rhatdan Sure makes sense. I was also worried about this difference between mac and podman-remote server. Copy should work for both of these cases. I'll amend my PR.

@flouthoc flouthoc force-pushed the api-allow-secrets branch 6 times, most recently from e2b9d35 to 4a8f997 Compare November 26, 2021 17:47
@flouthoc flouthoc marked this pull request as ready for review November 26, 2021 20:01
@openshift-ci openshift-ci bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Nov 26, 2021
test/e2e/build_test.go Outdated Show resolved Hide resolved
pkg/bindings/images/build.go Outdated Show resolved Hide resolved
test/e2e/build_test.go Show resolved Hide resolved
@vrothberg
Copy link
Member

@ashley-cui PTAL

@flouthoc
Copy link
Collaborator Author

@vrothberg thanks resolved in latest commit.

@flouthoc flouthoc requested a review from vrothberg November 29, 2021 10:38
Copy link
Member

@ashley-cui ashley-cui left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks!

@mheon
Copy link
Member

mheon commented Nov 29, 2021

Should we consider any additional security here, given this is secret data? I'm a little concerned that they might be included in built images unintentionally if an image does something like COPY *

@rhatdan
Copy link
Member

rhatdan commented Nov 29, 2021

/approve

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Nov 29, 2021

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: flouthoc, rhatdan

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Nov 29, 2021
@rhatdan
Copy link
Member

rhatdan commented Nov 29, 2021

@flouthoc please test out @mheon possiblity. Basically try a Containerfile with

from fedor
copy * /test/

And then run a test like

podman --remote -f /LOCATIONOF/Containerfile --secret ... /NOTLOCATIONOFContainerfile

Then make sure the secret and Containerfile do not end up i the image.

@flouthoc
Copy link
Collaborator Author

flouthoc commented Nov 29, 2021

@mheon @rhatdan I tested this with docker and buildkit : COPY * / is a user driven command even docker copies everything to working directory from current context. If build secret file is in current context and user wants to run COPY * / all files will be copied over since that is what user wants.

I guess we could workaround that by adding extra .dockerignore if we want but that would a different behavior though.

PS: Docker copies everything including Dockerfile and so do we.

@mheon
Copy link
Member

mheon commented Nov 29, 2021

But does Buildkit move all secrets into the build context, if they weren't already? Because it seems like that's what this code is doing.

@flouthoc
Copy link
Collaborator Author

flouthoc commented Nov 29, 2021

@mheon I haven't tried it on mac but i think it should not add secrets to context if they not part of it by default cause they must be binding files instead of copying it to context.

I guess we could have a similar thing by checking if secret was not part of current context then add it to .dockerignore that should be able to achieve us a similar functionality.

@flouthoc flouthoc force-pushed the api-allow-secrets branch 2 times, most recently from 8a22f22 to 316b5fe Compare November 30, 2021 08:48
Following commit makes sure that `build` api can accept external
secret and allows currently `NOOP` `podman-remote build -t tag
--secret id=mysecret,src=/path/on/remote` to become functional.

Just like `docker` following api is a hidden field and only exposed to
`podman-remote` but could document it if it needs exposed on `swagger`.

Signed-off-by: Aditya Rajan <[email protected]>
Podman remote must treat build secrets as part of context directory. If
secret path is absolute path on host copy it to tar file and pass it to
remote server.

Signed-off-by: Aditya Rajan <[email protected]>
@flouthoc
Copy link
Collaborator Author

flouthoc commented Nov 30, 2021

@flouthoc please test out @mheon possiblity. Basically try a Containerfile with

from fedor copy * /test/

And then run a test like

podman --remote -f /LOCATIONOF/Containerfile --secret ... /NOTLOCATIONOFContainerfile

Then make sure the secret and Containerfile do not end up i the image.

@mheon @rhatdan Following case of leaking secrets into image is handled in a new commit also added a new test to verify the same.

Prevents temp secrets leaking into image by moving it away from context
directory to parent builder directory. Builder directory automatically
gets cleaned up when we are done with the build.

Signed-off-by: Aditya Rajan <[email protected]>
@flouthoc
Copy link
Collaborator Author

@rhatdan @mheon PTAL. New test verifies the concern.

builderDirectory, _ := filepath.Split(contextDirectory)
// following path is outside build context
newSecretPath := filepath.Join(builderDirectory, arr[1])
oldSecretPath := filepath.Join(contextDirectory, arr[1])
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we clean this directory out anywhere, remove the files inside it? Is it shared between multiple builds, potentially?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mheon Yes build directory is automatically cleaned up and no its a new temp directory for each build.

@flouthoc flouthoc requested a review from mheon November 30, 2021 15:21
@mheon
Copy link
Member

mheon commented Nov 30, 2021

LGTM

@flouthoc
Copy link
Collaborator Author

@rhatdan PTAL

@rhatdan
Copy link
Member

rhatdan commented Nov 30, 2021

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Nov 30, 2021
@openshift-merge-robot openshift-merge-robot merged commit 85101f6 into containers:main Nov 30, 2021
@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 22, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 22, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

secret is not mounted during build (macos)
6 participants