Infisical / infisical

♾ Infisical is the open-source secret management platform: Sync secrets across your team/infrastructure, prevent secret leaks, and manage internal PKI
https://infisical.com
Other
15.17k stars 879 forks source link

Portainer integration #1281

Closed Emiliaaah closed 1 month ago

Emiliaaah commented 8 months ago

Feature description

It would be great if there was some way to sync secrets in Infisical to the environment variables for a docker stack and automatically deploy the stack with the new variables.

Why would it be useful?

This would make integrating Infisical a lot easier in environments using portainer to manage all docker stacks.

Additional context

Currently the best option (in my opinion) is using the Infisical agent. You can use the agent to write environment variables to a docker volume which portainer has access to to then reference this file in the docker compose using the env_file directive. When I was trying to set this up I ran into an issue though. In your docker compose files you can use environment variables passed into your compose command anywhere in your compose file, which includes referencing them in labels for a service, or basically anywhere else.

Since portainer loads in the environment variables it has stored itself you can reference these just like normal everywhere in your compose file. Unlike my solution with the Infisical agent.

Pushing these new variables can quite easily be applied using the portainer API, from my quick look through the portainer API.

Emiliaaah commented 8 months ago

The 2 options I've thought of to implement this so far (in hindsight only really 1) are as follows:

Option 1 would be implementing the just like the Cloud integrations, this option wouldn't be viable since Infisical would need to be able to access the portainer API which is hosted locally and in normal circumstances not exposed to the internet.

Option 2 would be implementing them into the cli agent. I think this would be the better option overall, since you wouldn't have the issue mentioned in option 1, you also have more control over how your config looks using the templates. Something this enables injecting secrets from other projects into this one (wouldn't really be needed that much if you could already share these variables server side). Here's just a rough example of how the config could look like with this implemented.

infisical:
  address: "https://app.infisical.com"
auth:
  - type: "universal-auth"
    config:
      client-id: "./client-id"
      client-secret: "./client-secret"
      remove_client_secret_on_read: false
  - type: "portainer"
    config:
      username: "my-username"
      password: "my-super-secure-password"
sinks:
  - type: "file"
    config:
      path: "/some/path/to/store/access-token/file-name"
templates:
  # type: file would in this case be the default if none specified and would act like how the agent currently works
  - source-path: my-dot-ev-secret-template
    destination-path: /some/path/.env
  - type: portainer
    source-path: my-dot-ev-secret-template
    stack_id: 1

For the templates you might want to also put all the setting under "config" like what is being done for auth and sinks instead of doing it like in my example.

Emiliaaah commented 8 months ago

Depending on where and how we intend to implement this I wouldn't mind taking a shot at implementing this myself.

The comment above is like I've said only a rough sketch and in no way final, but I'd love to get some feedback on this. And hopefully work this out some more, if this feature is something you find fitting for this Infisical.

radhakrisri commented 7 months ago

+1 to the proposal.

A couple of suggestions, I'd like to make, as modifications to the proposal:

  1. A stack might contain multiple containers, so we need some mechanism to specify a container that the secret template should be passed to. Maybe stack_id and container_name?
  2. A typical portainer usage will have stacks being brought to life at different points in time. I think we need to be able to "reload" the template configs into the agent on the fly, rather than having the agent being restarted every single time.