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
{{ message }}
This repository has been archived by the owner on Jan 8, 2024. It is now read-only.
I was trying to build something similar but in general instead of verifying from the orchestrator whether a task has been launched with the given name, I was trying to use the image id of the container being launched.
If the two can be combined:
If the given service or task has been launched
The task has been launched with the given image id
Then it would be more secure to deliver correct secrets to correct containers. Which secrets are to be delivered usually depends on the image and suppose if a task with the same name is launched with different image the secrets can be restricted to be available.
This approach might introduce some more work from the side of the secrets manager because every time an image is updated the image id will change and so the person has to change the vault configuration but this will also prevent leaking secrets into containers that no longer requires it.
Or at least this can be controlled via a flag so that in development mode one can avoid changing the image ids time and again.
The text was updated successfully, but these errors were encountered:
In the current version of Gatekeeper, you can use the --use-image-name option to have your policy names be defined by the docker image running in the task. For example with a policy file such as:
I was trying to build something similar but in general instead of verifying from the orchestrator whether a task has been launched with the given name, I was trying to use the image id of the container being launched.
If the two can be combined:
Then it would be more secure to deliver correct secrets to correct containers. Which secrets are to be delivered usually depends on the image and suppose if a task with the same name is launched with different image the secrets can be restricted to be available.
This approach might introduce some more work from the side of the secrets manager because every time an image is updated the image id will change and so the person has to change the vault configuration but this will also prevent leaking secrets into containers that no longer requires it.
Or at least this can be controlled via a flag so that in development mode one can avoid changing the image ids time and again.
The text was updated successfully, but these errors were encountered: