hi, I'm new to Cerbos, looking into using it as a sidecar container. I'm trying to understand what this log output means:

{"log.level":"info","@timestamp":"2022-05-30T17:47:05.452Z","log.logger":"cerbos.server","message":"maxprocs: Leaving GOMAXPROCS=8: CPU quota undefined"}
{"log.level":"info","@timestamp":"2022-05-30T17:47:05.452Z","log.logger":"cerbos.server","message":"Loading configuration from /config/config.yaml"}
{"log.level":"debug","@timestamp":"2022-05-30T17:47:05.454Z","log.logger":"cerbos.index","message":"Index build failed","missing":null,"missing_scopes":null,"load_failures":null,"duplicates":[{"file":"account_resource.yaml","otherFile":"..2022_05_30_17_45_35.387152270/account_resource.yaml"},{"file":"quant_roles.yaml","otherFile":"..2022_05_30_17_45_35.387152270/quant_roles.yaml"},{"file":"team_resource.yaml","otherFile":"..2022_05_30_17_45_35.387152270/team_resource.yaml"},{"file":"user_resource.yaml","otherFile":"..2022_05_30_17_45_35.387152270/user_resource.yaml"}],"disabled":[]}
{"log.level":"info","@timestamp":"2022-05-30T17:47:05.454Z","log.logger":"cerbos.server","message":"maxprocs: No GOMAXPROCS change to reset"}
cerbos: error: failed to create store: failed to build index: missing imports=0, missing scopes=0, duplicate definitions=4, load failures=0

Does that mean there is an issue with the content in the policy files? The files are defined in a configmap and then mounted to the container. I've also ran a local compile with no errors.

Hi Harry, I think you have some duplicate policies according to the logs below;

cerbos: error: failed to create store: failed to build index: missing imports=0, missing scopes=0, duplicate definitions=4, load failures=0

duplicate definitions=4

indicates there are 4 duplicate pair of policies in the store. Following part of the logs can give you some hints in terms of what file is duplicate of another file;

[{"file":"account_resource.yaml","otherFile":"..2022_05_30_17_45_35.387152270/account_resource.yaml"},

{"file":"quant_roles.yaml","otherFile":"..2022_05_30_17_45_35.387152270/quant_roles.yaml"},

{"file":"team_resource.yaml","otherFile":"..2022_05_30_17_45_35.387152270/team_resource.yaml"},

{"file":"user_resource.yaml","otherFile":"..2022_05_30_17_45_35.387152270/user_resource.yaml"}],"disabled":[]}

There seems to be two

account_resource.yaml

files. Please let us know if this doesn’t help.

does the container create a copy of these? I only mount these once 🙂 I'll have a look, thank you

Hi Harry, did you manage to fix the issue? The Cerbos container does not create copies of the files. Do you have some kind of backup or versioning process that could be creating copies of the files? The file names seem to suggest some kind of automated system is at work.

hi @Charith (Cerbos) turns out that kubernetes default behaviour when mounting volumes from configmaps is to create this folder structure so it can refresh when upstream changes:

ls -l /policies/
..
..2022_05_31_10_14_55.466267689
..data -> ..2022_05_31_10_14_55.466267689
account_resource.yaml -> ..data/account_resource.yaml
roles.yaml -> ..data/quant_roles.yaml
team_resource.yaml -> ..data/team_resource.yaml
user_resource.yaml -> ..data/user_resource.yaml

I think cerbos looks in the root dir and sees symlinks and then the actual files thinking they are duplicates the workaround was to point to the ..data subdir instead:

disk:
        directory: /policies/..data

That's interesting. What is the version of Kubernetes you are running? I haven't seen that behaviour before with config maps. Are you using a special storage plugin by any chance?

I've run into this before - I think it is the default behaviour. I was able to reproduce it with

kind

. I raised it as https://github.com/cerbos/cerbos/issues/969