You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment the Opal administrator password is passed as an environment variable to the container to set when the container is started for the first time. The most secure option is to store that password in an .env file and set the permission to 400, so that only root has access. This is OK, but some may object to having the password in plain text at all, for example in case someone forgets to set the permissions to 400 or the .env file is accidentally checked into Github.
Docker secrets can be used in swarm mode. However, some additional coding is required to get the secret into an environment variable to be consumed by the container. This requires some extra code in the container start up (see here). It is this extra code that could be added to the Opal image. This means that the passwords are not stored in plain text anywhere and are unlikely to be accidentally included in a check in.
The disadvantage of this method is that running in swarm mode might offer more complexity in terms of debugging etc. It does seem possible to add new Rock containers, but I have not tested extensively adding, removing and scaling them. It is more complex for the user to set up.
The text was updated successfully, but these errors were encountered:
At the moment the Opal administrator password is passed as an environment variable to the container to set when the container is started for the first time. The most secure option is to store that password in an
.env
file and set the permission to 400, so that only root has access. This is OK, but some may object to having the password in plain text at all, for example in case someone forgets to set the permissions to 400 or the.env
file is accidentally checked into Github.Docker secrets can be used in swarm mode. However, some additional coding is required to get the secret into an environment variable to be consumed by the container. This requires some extra code in the container start up (see here). It is this extra code that could be added to the Opal image. This means that the passwords are not stored in plain text anywhere and are unlikely to be accidentally included in a check in.
The disadvantage of this method is that running in swarm mode might offer more complexity in terms of debugging etc. It does seem possible to add new Rock containers, but I have not tested extensively adding, removing and scaling them. It is more complex for the user to set up.
The text was updated successfully, but these errors were encountered: