Secret as environment variables in non-plugin images

Drone Support
1

Here is a fragment of my config

 docker:
    image: plugins/docker:linux-arm
    repo: registry/img1
    registry: registry
    tags: latest
    secrets: [ docker_username, docker_password ]
  deploy:
    privileged: true
    image: docker:18-dind
    secrets: [ docker_username, docker_password ]
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    commands:
      - "echo $DOCKER_USERNAME"
      - "echo $$DOCKER_USERNAME"
      - "docker login --username=$$DOCKER_USERNAME --password=$$DOCKER_PASSWORD registry"
      - "docker service update --image registry/img1:latest my-service"

I am attaching secrets to both steps, but in the first one it works, in the second (with all variations of the escaping syntax) echos print nothing. It is probably due to the fact that in the first step we work with the Drone plugin and in the latter use just use a generid DIND image. Is this the root cause? Are exposure of secrets to custom images supported?

What I am trying to do: In order to update the swarm service I expose the host socket to a privileged step running dind (do I even need a dind?). While the “docker service update” command works without login, it does not have access to the registry, as a result

image registry/img1:latest could not be accessed on a registry to record
its digest. Each node will access registry/img1:latest independently,
possibly leading to different nodes running different versions of the image.

2

escaping is only required for ${VARIALBE} syntax (with braces), not for $VARIALBE syntax (without braces).

3

False alarm, I did not have added the image to the secret settings :frowning: This was hard to debug, as it is silently empty, but allows to use the secret in the config, no failure

4

Thanks, I will fix that :slight_smile: I also found the problem, see below. Is this intentional that the secret is not validated for access and fail hard if it is not permitted for this image?

5

Is this intentional that the secret is not validated for access and fail hard if it is not permitted for this image?

yes, the decision to execute steps even when a secret is not available is intentional. This is because there are valid use cases where a step needs to execute even if the secret is not exposed. The most common use case are test suites that rely on credentials (keys, etc) that are skipped if the credentials are not present (hidden from pull requests, etc).

You can see an example of such test suite here: