Added X-Drone-Branches Filter

[null93]

Description

The following pull request extends the current functionality of the drone-vault extension. In particular a new filter type was added. In addition to X-Drone-Repos and X-Drone-Events, X-Drone-Branches can now be specified. When a pipeline is triggered, the target branch will be used for filtering. This pull request also extends the test suite to ensure proper functionality of this newly added filter type.

Use Case

Lets assume we have a simple CD process:

• When pushing to the master branch, build docker image and push to a private production docker registry.
• When pushing to the development branch, build docker image and push to a private development docker registry.
• Using protected branches on Github, protect pushes to master branch to allow only trusted people to push to it.

The above assumes that we store the production docker images separate from all other ones because they either might contain production grade information or we do not want anyone with push privileges to the development branch to override an image. An example could be an SSL cert baked into the docker image. Our goal is not to let people who have push privileges to the development branch be able to push their image to the production private registry.

Assume that the following information is stored within Vault:

docker-registry/data/production/registry_username=prod-username
docker-registry/data/production/registry_password=prod-password
docker-registry/data/production/x-drone-repos=foo/*
docker-registry/data/production/x-drone-events=push
docker-registry/data/development/registry_username=dev-username
docker-registry/data/development/registry_password=dev-password
docker-registry/data/development/x-drone-repos=foo/*
docker-registry/data/development/x-drone-events=push

Consider the the following Drone configuration:

kind: pipeline
name: Development

trigger:
    branch:
    -   development
    event:
    -   push
steps:
-   name: docker-image
    image: plugins/docker
    settings:
        registry: development-registry.example.com
        username:
            from_secret: development_registry_username
        password:
            from_secret: development_registry_password
        repo: development-registry.example.com/foo/bar
        tags: latest

---

kind: pipeline
name: Production

trigger:
    branch:
    -   master
    event:
    -   push
steps:
-   name: docker-image
    image: plugins/docker
    settings:
        registry: production-registry.example.com
        username:
            from_secret: production_registry_username
        password:
            from_secret: production_registry_password
        repo: production-registry.example.com/foo/bar
        tags: latest

---

kind: secret
name: development_registry_username
get:
    path: docker-registry/data/development
    name: registry_username

---

kind: secret
name: development_registry_password
get:
    path: docker-registry/data/development
    name: registry_password

---

kind: secret
name: production_registry_username
get:
    path: docker-registry/data/production
    name: registry_username

---

kind: secret
name: production_registry_password
get:
    path: docker-registry/data/production
    name: registry_password

With the current setup, a malicious actor with push privileges to development branch, has access to the production credentials.

How To Fix This Issue

With this new filter we can eliminate this security risk. Let us now assume that the following information is stored within Vault:

docker-registry/data/production/registry_username=prod-username
docker-registry/data/production/registry_password=prod-password
docker-registry/data/production/x-drone-repos=foo/*
docker-registry/data/production/x-drone-events=push
docker-registry/data/production/x-drone-branches=master
docker-registry/data/development/registry_username=dev-username
docker-registry/data/development/registry_password=dev-password
docker-registry/data/development/x-drone-repos=foo/*
docker-registry/data/development/x-drone-events=push
docker-registry/data/development/x-drone-branches=development

This solves the issue because now when the Development pipeline is triggered, it does not have access to the production registry secrets.

Possible Implications

I could not think of any possible negative implications that these changes might cause. If you choose not to use this new filter, then everything works as it did before.

Additional Information

When filtering, the target branch name is considered. That means that if the event does not have metadata about the target branch (i.e. when event is 'tag'), then permission is not given.

For testing purposes an image with this filter implemented can be pulled from jetrails/drone-vault:latest. It will be available for the lifetime of this pull request.

[CLAassistant]

All committers have signed the CLA.

[bradrydzewski]

thank you, I really appreciate the detailed proposal and the unit tests :)

[null93]

Thanks for merging it in! Glad I can contribute something.