Forbidden access to S3-compatible Object Storage about docker-cowrie HOT 14 CLOSED

So looking at https://docs.aws.amazon.com/AmazonS3/latest/dev/using-with-s3-actions.html the head object seem to require s3:getObject which you give, so I think you give the right acces rights.

from docker-cowrie.

this could help: https://aws.amazon.com/premiumsupport/knowledge-center/s3-troubleshoot-403/ ?

from docker-cowrie.

Does your policy need a principal entry?

from docker-cowrie.

What if you try it from a non-dockered cowrie?

from docker-cowrie.

Does your policy need a principal entry?

It doesn't seem so (referring in this specific case to the MinIO documentation on users and access control). Policies are applied to users in a second step.

from docker-cowrie.

What if you try it from a non-dockered cowrie?

I'll try that 👍

from docker-cowrie.

Yup, I can confirm that in a non-dockerized cowrie instance everything works fine 👍 at least the whole S3 setup wasn't for nothing 😅
That's weird though... does Docker's network adapter change request headers? 🤔

from docker-cowrie.

from docker-cowrie.

from docker-cowrie.

botocore is 1.15.x on both environments, while awscli is not present in either... The system time issue sounds interesting. I'll try to tap a request that arrives on the backend to check what parameters it is sent, might help with debugging that.

from docker-cowrie.

Well... sure enough I start tapping and today everything works as expected even in the dockerized cowrie 😒. Coincidentally yesterday we entered summer time here in Central Europe... so I tried messing with the system clock manually and restarting the Docker daemon (since apparently "Docker uses the same clock as the host and the [container] cannot change it", see this SO answer) and yes, that is indeed the issue... Tbh I thought the S3 signature mechanism would be based only on the data received in the headers (timestamp included) 🤔 , so it never crossed my mind that time differences between machines could be an issue.

All this means that the timing of your answer was perfect 😄 had I tried running a non-dockerized cowrie instance last week it wouldn't have worked.

Now I only have to find a way to keep cowrie deployments and the S3 backend always in sync, but that's not a cowrie issue 👍

Thanks a lot for the support @micheloosterhof and in general for your work on cowrie 🙏

from docker-cowrie.

Actually, I think I jumped to conclusions too fast. Last week I would be able to access S3 from a simple virtual environment, but not from inside the container. Yet the host was the same, so something must be still off with Docker...

from docker-cowrie.

from docker-cowrie.

Yes, I'll most likely do that.
I unfortunately haven't been able to exactly reproduce last week's conditions by manually changing the system clock... If I do that I get a 403 in both cases now 🤔 bah, who knows...
In any case thank you!

from docker-cowrie.