Permalink
Commits on Aug 18, 2017
  1. plugable secret backend - update vendor.conf

    liron-l committed Jul 31, 2017
    Updating swarmkit dependencies.
    
    Add more parameters for the secret driver API.
    
    Signed-off-by: Liron Levin <liron@twistlock.com>
Commits on Jul 18, 2017
  1. pluggable secret backend

    liron-l committed Jul 18, 2017
    Fixing secret driver serialization issue from
    08f7cf0
    
    Signed-off-by: Liron Levin <liron@twistlock.com>
Commits on Jul 15, 2017
  1. pluggable secret backend

    liron-l committed Jul 15, 2017
    This commit extends SwarmKit secret management with pluggable secret
    backends support.
    
    Updating the work in
    [swarmkit](docker/swarmkit@eebac27) for
    pluggable secret backend and adding the
    driver parameter to `SecretSpec`.
    
    Remaining work:
    - [ ] CLI support (docker/cli)
    - [ ] api in [plugin helpers](docker/go-plugins-helpers))
    - [ ] Reference plugin
    - [ ] Documenation (after cli work)
    
    Signed-off-by: Liron Levin <liron@twistlock.com>
Commits on Jul 30, 2016
  1. Enable to dynamically reload authorization plugins via daemon.config

    liron-l committed May 16, 2016
    Following #22729, enable to dynamically reload/remove the daemon
    authorization plugins (via standard reloading mechanism).
    https://docs.docker.com/engine/reference/commandline/daemon/#daemon-
    configuration-file
    
    Daemon must store a reference to the authorization middleware to refresh
    the plugin on configuration changes.
    
    Signed-off-by: Liron Levin <liron@twistlock.com>
Commits on May 2, 2016
  1. Remove response modification sections from authorization design doc

    liron-l committed May 2, 2016
    Signed-off-by: Liron Levin <liron@twistlock.com>
  2. Fix authorization issue - when request is denied return forbbiden exi…

    liron-l committed May 2, 2016
    …st code (403).
    
    - Return 403 (forbidden) when request is denied in authorization flows
    (including integration test)
    - Fix #22428
    - Close #22431
    
    Signed-off-by: Liron Levin <liron@twistlock.com>
Commits on Mar 30, 2016
  1. Add short description about default authentication method in authoriz…

    liron-l committed Mar 30, 2016
    …ation docs
    
    Following the discussion in #21556, adding a short description of the
    default user authentication mechanism (without requiring authentication
    plugins)
    Signed-off-by: Liron Levin <liron@twistlock.com>
Commits on Mar 27, 2016
  1. Extend Docker authorization with TLS user information

    liron-l committed Mar 27, 2016
    Currently Docker authorization framework does not use any user
    information, which already available in the Docker context for TLS
    connection.
    The purpose of this CR is to complete the existing authz work by adding
    the basic client certificate details (SUBJECT_NAME) and authentication
    method (TLS) to the authz request.
    
    We think this should be the default behavior when no extended
    authorization module is specified (currently WIP under #20883).
    
    Signed-off-by: Liron Levin <liron@twistlock.com>
Commits on Mar 14, 2016
  1. Run privileged containers when userns are specified

    liron-l committed Feb 8, 2016
    Following #19995 and #17409 this PR enables skipping userns re-mapping
    when creating a container (or when executing a command). Thus, enabling
    privileged containers running side by side with userns remapped
    containers.
    
    The feature is enabled by specifying ```--userns:host```, which will not
    remapped the user if userns are applied. If this flag is not specified,
    the existing behavior (which blocks specific privileged operation)
    remains.
    
    Signed-off-by: Liron Levin <liron@twistlock.com>
Commits on Feb 25, 2016
  1. Fix #20508 - Authz plugin enabled with large text/JSON POST payload c…

    liron-l committed Feb 23, 2016
    …orrupts body
    
    Based on the discussion, we have changed the following:
    
    1. Send body only if content-type is application/json (based on the
    Docker official daemon REST specification, this is the provided for all
    APIs that requires authorization.
    
    2. Correctly verify that the msg body is smaller than max cap (this was
    the actual bug). Fix includes UT.
    
    3. Minor: Check content length > 0 (it was -1 for load, altough an
    attacker can still modify this)
    
    Signed-off-by: Liron Levin <liron@twistlock.com>
Commits on Feb 9, 2016
  1. Move userns cli test to a separate file, remove experimental flag

    liron-l committed Feb 8, 2016
    Signed-off-by: Liron Levin <liron@twistlock.com>
Commits on Feb 5, 2016
  1. Fix 19575: Docker events doesn't work with authorization plugin

    liron-l committed Feb 4, 2016
    To support the requirement of blocking the request after the daemon
    responded the authorization plugin use a `response recorder` that replay
    the response after the flow ends.
    
    This commit adds support for commands that hijack the connection and
    flushes data via the http.Flusher interface. This resolves the error
    with the event endpoint.
    
    Signed-off-by: Liron Levin <liron@twistlock.com>
Commits on Feb 3, 2016
  1. user namespaces: duplicate dot in user namespaces error message

    liron-l committed Feb 3, 2016
    duplicate dot in user namespaces error message:
    
    $ docker run -ti --net=host ubuntu /bin/bash
    docker: Error response from daemon: Cannot share the host or a
    container's network namespace when user namespaces are enabled..
    
    Signed-off-by: Liron Levin <liron@twistlock.com>
Commits on Dec 11, 2015
  1. Change authz plugin argument name

    liron-l committed Dec 11, 2015
    Signed-off-by: Liron Levin <liron@twistlock.com>
Commits on Dec 8, 2015
  1. Rebase from master

    liron-l committed Dec 8, 2015
    Signed-off-by: Liron Levin <liron@twistlock.com>
  2. Docker authorization plug-in infrastructure enables extending the fun…

    liron-l committed Nov 12, 2015
    …ctionality of the Docker daemon with respect to user authorization. The infrastructure enables registering a set of external authorization plug-in. Each plug-in receives information about the user and the request and decides whether to allow or deny the request. Only in case all plug-ins allow accessing the resource the access is granted.
    
    Each plug-in operates as a separate service, and registers with Docker
    through general (plug-ins API)
    [https://blog.docker.com/2015/06/extending-docker-with-plugins/]. No
    Docker daemon recompilation is required in order to add / remove an
    authentication plug-in. Each plug-in is notified twice for each
    operation: 1) before the operation is performed and, 2) before the
    response is returned to the client. The plug-ins can modify the response
    that is returned to the client.
    
    The authorization depends on the authorization effort that takes place
    in parallel [#13697].
    
    This is the official issue of the authorization effort:
    #14674
    
    (Here)[https://github.com/rhatdan/docker-rbac] you can find an open
    document that discusses a default RBAC plug-in for Docker.
    
    Signed-off-by: Liron Levin <liron@twistlock.com>
    Added container create flow test and extended the verification for ps