Implement policy configuration scopes in docker-daemon: #301
Conversation
This file contains hidden or 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
mtrmac
force-pushed
the
daemon-identity
branch
2 times, most recently
from
cce8846 to
c391621
Compare
mtrmac
force-pushed
the
daemon-identity
branch
3 times, most recently
from
eb9d3d2 to
57f8a10
Compare
mtrmac
force-pushed
the
daemon-identity
branch
3 times, most recently
from
45c27a7 to
6ba63c8
Compare
mtrmac
force-pushed
the
daemon-identity
branch
from
6ba63c8 to
340a90a
Compare
mtrmac
force-pushed
the
daemon-identity
branch
from
340a90a to
d4ee5a6
Compare
Collaborator
Author
|
@runcom PTAL |
mtrmac
force-pushed
the
daemon-identity
branch
2 times, most recently
from
bda3e03 to
b289110
Compare
mtrmac
force-pushed
the
daemon-identity
branch
from
b289110 to
1beafae
Compare
mtrmac
force-pushed
the
daemon-identity
branch
2 times, most recently
from
1082b7b to
685c0b6
Compare
mtrmac
force-pushed
the
daemon-identity
branch
2 times, most recently
from
128f717 to
698e669
Compare
mtrmac
force-pushed
the
daemon-identity
branch
2 times, most recently
from
a0433ae to
0be99d2
Compare
mtrmac
force-pushed
the
daemon-identity
branch
from
0be99d2 to
d87be77
Compare
mtrmac
force-pushed
the
daemon-identity
branch
from
d87be77 to
281a61b
Compare
Member
|
@runcom Could you take a look at this. |
mtrmac
force-pushed
the
daemon-identity
branch
from
281a61b to
e3db60e
Compare
mtrmac
force-pushed
the
daemon-identity
branch
2 times, most recently
from
aa989d3 to
2457de4
Compare
mtrmac
force-pushed
the
daemon-identity
branch
2 times, most recently
from
4d08a85 to
bbd05bb
Compare
mtrmac
force-pushed
the
daemon-identity
branch
2 times, most recently
from
cfdbb39 to
c98ae5e
Compare
Member
|
@umohnani8 PTAL |
Member
|
LGTM |
Member
|
LGTM |
Member
|
LGTM |
Member
|
LGTM, needs rebase though. |
This is necessary for verification / policy enforcement of in-daemon images. It is awkward in that an image may have no name and be usable only by an ID; such IDs could have a policy identity but they can’t really be namespaced. For now, implement policy configuration scopes only for named image references; ID-only references use the root scope. This allows users to make ID-only images untrusted or to reject them, forcing users to use image names if they want the policy to approve. This gives a fairly natural semantics, equivalent to docker: policies. ID-like policy configuration scopes are forbidden. If truly necessary, we can add support for single-ID policy IDs into the policy in the future, but that’s unlikely to be too useful—IDs change over time, so such a policy would not be likely to be persistent; and a single-use policy built for a single image can just as well use the universal "" scope. (Note that docker-daemon: and docker: namespaces are still separate in the policy—images from any source can be loaded into the daemon via (docker load) / copy to docker-daemon:, so there is in general no expectation that the two namespaces are equal. Though a special-purpose tool may well want to create an in-memory policy by loading the system-wide one and grafting the docker: PolicyTransportScopes map to docker-daemon: as well.) [In many cases an image will have an unique RepoTags/RepoDigests value which can be used to get _a_ name from the ID, probably the right guess. For now we keep the ImageReference implementation dumb, though inspecting the image by ID and giving the reference a tagged/digested name is at least plausible in principle. Special-purpose tools can script this without having to wait for daemonReference to add this.] Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Collaborator
Author
|
👍 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
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.
This is necessary for verification / policy enforcement of in-daemon images. (#288)
It is awkward in that an image may have no name and be usable only by an ID; such IDs could have a policy identity but they can’t really be namespaced.
For now, implement policy configuration scopes only for named image references; ID-only references use the root scope. This allows users to make ID-only images untrusted or to reject them, forcing users to use image names if they want the policy to approve. This gives a fairly natural semantics, equivalent to
docker:policies. ID-like policy configuration scopes are forbidden. If truly necessary, we can add support for single-ID policy IDs into the policy in the future, but that’s unlikely to be too useful—IDs change over time, so such a policy would not be likely to be persistent; and a single-use policy built for a single image can just as well use the universal""scope.(Note that
docker-daemon:anddocker:namespaces are still separate in the policy—images from any source can be loaded into the daemon via(docker load)/ copy todocker-daemon:, so there is in general no expectation that the two namespaces are equal. Though a special-purpose tool may well want to create an in-memory policy by loading the system-wide one and grafting thedocker:PolicyTransportScopesmap todocker-daemon:as well.)[In many cases an image will have an unique
RepoTags/RepoDigestsvalue which can be used to get a name from the ID, probably the right guess. For now we keep theImageReferenceimplementation dumb, though inspecting the image by ID and giving the reference a tagged/digestedname is at least plausible in principle. Special-purpose tools can script this without having to wait for
daemonReferenceto add this.]