Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

block.kontain.me #66

Open
Dentrax opened this issue Nov 16, 2021 · 3 comments
Open

block.kontain.me #66

Dentrax opened this issue Nov 16, 2021 · 3 comments

Comments

@Dentrax
Copy link

Dentrax commented Nov 16, 2021

Block the image pull operation for such cases:

  • specific image tag (i.e. latest)
  • specific image digest
  • specific image tag (if digest changed)
  • specific image name
  • specific image registry

The idea is to simulate the following cases:

  • if target image ref is gone in the remote
  • if someone overridden the image tag (and digest is changed)
  • if image or registry got zero-day compromise?

Not sure which HTTP status we should return for these situations.

@imjasonh
Copy link
Owner

This sounds useful for chaos testing registry clients. I like it.

The only question I have is how the behavior should be configured. Should we just hard-code certain behaviors into the registry (i.e., chaos.kontain.me/ubuntu always fails to pull by tag)? Should it be something a user can configure and POST to the registry? I'm open to ideas.

Blocking pulling images by tag if the tag has changed sounds roughly like the goal of https://github.com/imjasonh/kontain.me/tree/main/cmd/transparency, which I haven't finished yet.

@Dentrax
Copy link
Author

Dentrax commented Nov 16, 2021

Oh, I see. Putting configs in hardcoded state requires a recompilation so I'm slightly -1 for this idea. It would be nice to pass a config.yaml to server using viper as a config parser. One tradeoff here would be the limitation to change the configuration during runtime. In anyway, we probably need to decide a config spec. If we decide to impl config logic for this one, should we design it to cover all the other service types?

@imjasonh
Copy link
Owner

I mean, it's a hacky registry for fun, I don't care if its rules are hard-coded or pulled from a config file at startup. The point of it all is to build something fun. There's no reason to design it for real life.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants