container brought up with docker-compose fails with access denied error

[edsanks]

Describe the bug
If the docker command env variables (account, password, maintainer-timeout etc) are put in the docker-compose.yaml and brought up by running docker-compose up, then the curl commands throw a response message as Access Denied. The same curl command outputs JSON with valid account info if the docker run --env option was used to bring it up.

To Reproduce
Steps to reproduce the behavior:

1. Make sure you have docker installed, updated and running in your local (laptop) test environment. (I am running on macos big sur 11.6.3)
2. Assuming that voyz/ibeam is already pulled into your environment.
3. using your editor, create docker-compose.yaml with the following syntax and your own values:

services:
  app:
    image: voyz/ibeam
    environment:
      IBEAM_ACCOUNT: <my-IB-account-name>
      IBEAM_PASSWORD: <my-IB-account-password>
      IBEAM_MAINTENANCE_INTERVAL: 3600
    ports:
      - "5000:5000"

4. Run the container using the command: docker-compose up (btw, docker-compose --version shows 2.2.3)
5. Observe the bring up messages to make sure the authentication is successful - (expect to see lines: Authentication process succeeded and Gateway running and authenticated)
6. Now fire off your curl command: curl -X GET "https://localhost:5000/v1/api/portfolio/accounts" -k and see what it throws. (I got Access Denied).
7. This same command works perfectly if I bring up docker with syntax listed in the readme in this site page.

Expected behavior
The fact that the authentication is succeeded, it should also handle API to get portfolio/accounts etc.

Environment
IBeam version: Starting IBeam version 0.3.0
Docker image or standalone: Docker image pulled from this site and no changes.
Python version (standalone users only): Not applicable as I ran docker image directly.
OS: MacOS Big Sur 11.6.3

Additional context
Docker version 20.10.12, build e91ed57
Docker Compose version v2.2.3

Suggest a Fix
N/A

[Voyz]

Hey @edsanks welcome to IBeam 😊👋 Thanks for providing all the details on this issue you're experiencing!

I'd start by observing that the docker-compose.yaml snippet you pasted seems to contain some syntax inconsistency. Just to rule out it being the cause of it, could you ensure that the environment variables you pass contain the hyphen - before them?

ie. change:

environment:
   IBEAM_ACCOUNT: <my-IB-account-name>
   IBEAM_PASSWORD: <my-IB-account-password>
   IBEAM_MAINTENANCE_INTERVAL: 3600

Into:

environment:
 - IBEAM_ACCOUNT: <my-IB-account-name>
 - IBEAM_PASSWORD: <my-IB-account-password>
 - IBEAM_MAINTENANCE_INTERVAL: 3600

We'll look into other possibilities once we know this is not the problem 👍

[edsanks]

Adding the '-' prefix in the docker-compose.yaml causes the command to simply exit with the following message:
services.app.environment must be a mapping.
So, I suppose the original syntax seems to be right. We can confirm that because the Maintenance Interval value is picked up and used as seen from the bring up messages previosuly.

[Voyz]

Okay, thanks for checking that. The services.app.environment must be a mapping. could indicate that there was something off with the indentation of your yaml file.

Could I ask you to paste the full docker-compose.yaml file contents (except for the sensitive data), as well as the output of running IBeam in debug?

[edsanks]

attaching a copy of the file used
docker-compose.yaml.usedcopy.zip

[Voyz]

Thanks for sending it over @edsanks

It seems to be in order syntax wise. Please add the following to your docker-compose.yaml and try again:

network_mode: bridge

Running IBeam through docker-compose creates a separate docker network that the Gateway seems to dislike.

[edsanks]

This is great find. It worked. Thanks for the assistance. I will try some more by deploying this on AWS ECS / EKS env and add some details, so it will help others.

[edsanks]

This is doing a decent job by deploying on ECS. One thing we noticed is, it chokes on curl command after a few minutes. I am trying a test for linearly higher backoff time and see what the idle timeout might be that could cause IB connection to choke. So far, a 90 second gap between curl calls has not caused a failure. Will try more like 2mins, 3mins and 4 mins gaps. Any known ideas on this?

Another thing I want to try is using 2FA automated. Any clues like operational steps and configs would be great. Happy to test it.

[edsanks]

So, the container choked after responding to two calls each 3-min apart.

[Voyz]

Hey @edsanks I'm happy to hear that 😊

Since the docker-compose failures seem to be resolved with the suggestion I made, I'm going to go ahead and close this issue - although feel free to reopen it if you see more Access Denied errors when running IBeam through docker-compose.

As for your other questions:

One thing we noticed is, it chokes on curl command after a few minutes. I am trying a test for linearly higher backoff time and see what the idle timeout might be that could cause IB connection to choke. So far, a 90 second gap between curl calls has not caused a failure. Will try more like 2mins, 3mins and 4 mins gaps. Any known ideas on this?

Very happy to help you look into it, however given that we'd like to keep issues issue-specific, could I ask you open a new issue describing this problem in detail where we could discuss how to solve it? There, please outline what does 'it chokes' mean - do you have any logs that show this behaviour? Thanks 👍

Another thing I want to try is using 2FA automated

While we don't have an official guide to 2FA automation, there is a number of discussions amongst the issues related to 2FA automation. I suggest you look through the existing conversations. I'd start by reading: https://github.com/Voyz/ibeam/wiki/Two-Factor-Authentication, #8 (comment) and #40 (comment)

[psalajka]

Hi,

at first, thanks for a great job, @Voyz .

I just went through hell with this "access denied" error. The network_mode: bridge helped to expose the port to the system, but make it inaccessible from other containers.

After all, the solution was simple: I run the container in a docker-compose on Windows 10 (with Docker Desktop). For some reason, IPs of my containers are 172.*.*.*, which IS NOT among allowed IPs in the default conf.yaml on Gateway Configuration.

So now, I have:

      index: "index.html"
ips:
  allow:
    - 192.*
    - 131.216.*
    - 127.0.0.1
    - 0.0.0.0
    - 172.17.0.*
    - 172.*
  deny:

and everything looks alright :-)

[Voyz]

hey @psalajka ! Glad to see you figured it out! Yes, the default allowed IPs cover only some ranges - you need to add custom Docker network IP ranges to config.yaml - good job 👍

[thunderwin]

I have the IP issue as well, My docker is working but deny me. I m using Docker-compose, how to make it work?

[psalajka]

Find the IP of your container. docker inspect should help. It should be in the "Networks" section. Then add it to allowed IPs in the conf.yaml (as I did). I did it precisely this way and then simply mounted the inputs directory (with the conf.yaml file) inside the IBeam container:

  ibeam:
    image: voyz/ibeam
    volumes:
      - ./ibeam/srv/inputs:/srv/inputs:ro