https://cerbos.dev logo
Title
m

Michael Perju

01/12/2023, 3:46 PM
Hi šŸ‘‹šŸ» I'm wondering if anyone has stumbled upon this issue before or a similar problem WHAT I'M TRYING TO DO By default, Cerbos is pulling the policies from Github via HTTPS. I want to change it to use SSH. Created the public/private keys, tested in multiple environments - pulling the repo WORKS. WHAT BLOCKS ME I configured Cerbos DOCKER container to use the SSH mechanism, but internally, it seems that it lacks some SSH configuration Here's the error:
{"log.level":"error","@timestamp":"2023-01-12T15:21:04.187Z","log.logger":"cerbos.git.store","message":"Failed to initialize git store","dir":"/policies","error":"failed to clone from git@github.com:utilitywarehouse/cerbos-policies.git to /policies: unable to find any valid known_hosts file, set SSH_KNOWN_HOSTS env variable"}
cerbos: error: failed to create store: failed to clone from git@github.com:utilitywarehouse/cerbos-policies.git to /policies: unable to find any valid known_hosts file, set SSH_KNOWN_HOSTS env variable
WHAT I'VE TRIED: ā€¢ Mounting a hardcoded
known_hosts
file - makes it WORK āœ… I am not sure this is a good approach, since the public keys of github may rotate in the future and the hardcoded file will be invalid. ā€¢ Mounting a
ssh_config
inside
/etc/ssh/ssh_config
, as well as in
/.ssh/config
, configuring SSH to ignore the
kown_hosts file
- Does not work āŒ THOUGHTS: At the moment, I think only hard-copying the
known_hosts
file. A better approach, though not standard, would be to ignore checking the known hosts at all. That is done via SSH configuration, but the docker image ignores any mounted configuration files.
c

Charith (Cerbos)

01/12/2023, 3:55 PM
Hi. What I'd recommend is generating the
known_hosts
file for just the host you're interested in (
ssh-keyscan <http://github.com|github.com>
) and mounting it at
/etc/ssh/ssh_known_hosts
. If you're in Kubernetes, you can do this with an init container as well.
We don't currently have a way to disable host key verification because it's a security risk. If the GitHub keys change (which happens very rarely), I think it's better to fail at that point and verify that the keys have indeed changed legitimately.
m

Michael Perju

01/12/2023, 10:09 PM
Hello Charith and thanks for the answer. Will hardcode it for now