Telescope 2.8 release

Release 2.8 was one of the biggest releases. Telescope set a new record with 99 tasks completed. So close to 100, but we will eventually make it one day.

What I did:

Use oauth2-proxy with GitHub Auth Provider to secure Admin apps
#3030 - This issue was to use oauth2-proxy to be our proxy with auth, to make it simple we want to secure some route, and only be accessible once authorize.
For this issue, we wanted to hide Portainer under oauth2-proxy.
I spend a couple of days doing research and trying oauth2-proxy in my local. I followed some sample of code https://github.com/oauth2-proxy/oauth2-proxy/blob/master/contrib/local-environment/docker-compose.yaml and run it locally. Instead of using oidc I switched to GitHub.

  oauth2-proxy:
    image: bitnami/oauth2-proxy:7.2.1
    container_name: 'oauth2-proxy'
    command:
      [
        '--provider=github',
        '--cookie-secure=false',
        '--cookie-secret=<Long_cookie>',
        '--upstream=<Redirect_to_after_login>',
        '--http-address=0.0.0.0:8080',
        '--skip-auth-regex=/forms/*',
        '--redirect-url=http://localhost:8085/oauth2/callback',
        '--email-domain=*',
        '--client-id=<Github_client_id>',
        '--client-secret=<Github_secret_id>',
      ]
    ports:
      - 8085:8080

I also need to setup GitHub oauth app. Followed this instruction.
https://docs.github.com/en/developers/apps/building-oauth-apps/creating-an-oauth-app
Once I have oauth2-proxy working locally it was time to head in telescope repo and implement this.

One issue I noticed is that Portainer doesn't have anymore an option to enable no-auth after V.1. So we will have to login twice once in our oauth2-proxy and another one in Portainer which is what we don't want.
I had to find another option to implement oauth with Github provider in Portainer. After a bit of documentation reading. I found out that Portainer has a custom oauth and can be setup with Github. see
It was time to setup custom oauth for Portainer. First I needed @humphd to setup Github oauth app in Seneca-CDOT, after that, I just had to put the correct information following this image below.

How the custom oauth in Portainer works, only the default admin can login through Internal authentication. All other users will need to login through Github.
To give access to a GitHub User, you will need to add a new user and match the username to their Github username. Once that is created, user can login with their Github account.

Login flow

• Go to the portainer URL
• Login with Github
• After authorize Conclusion of this, this issue what something simple but it required a bit of research. At the end I didn't implement oauth2-proxy but it's fine this research will help in securing route for supabase.

Set up Authorization tokens for CI #3
- This issue was to setup basic auth for our new Docker registry with docker_auth.
The documentation was just enough, I found it hard to setup since there is not a lot of sample code.

From reading from the docs we need a auth_config.yml.

server:
  addr: ':5001' # Address to listen to
  certificate: '/etc/letsencrypt/live/docker.cdot.systems/fullchain.pem' # TLS Certificate
  key: '/etc/letsencrypt/live/docker.cdot.systems/privkey.pem' # TLS Key

token:
  issuer: 'Docker auth issuer' # Issuer, must match issuer in the Registry config.
  expiration: 900

users:
  # Password is specified as a BCrypt hash. Use htpasswd to generate.
  'admin': # Setup an Admin account
    password: '' 
  'telescope-ci': # Setup an telescope-ci account for our CI
    password: '' 
  '': {} # Setup account that doesn't required password


acl:
  - match: { account: 'admin' } # Setup rule for admin to have full permission
    actions: ['*']
    comment: 'Admin has full access to everything.'
  - match: { account: 'telescope-ci' } # Setup rule for telescope-ci to have push and pull access.
    actions: ['push', 'pull']
    comment: 'Telescope CI has push and pull access'
  - match: { account: '' } # Setup rule for anyone else to have pull access.
    actions: ['pull']
    comment: 'Any user has pull access'

After this I have @TDDR, helped me out to setup the config.yml for the registry based on some of the comments I put in the Pull Request.

version: 0.1

#Log
log:
  level: info 
  fields:
    service: registry

# Storage 
storage:
  cache:
    blobdescriptor: inmemory
  filesystem:
    rootdirectory: /mnt/docker0storage/registry

# Address to listen to
http:
  addr: ':5000'

# Our auth
auth:
  token:
    issuer: 'Docker auth issuer' # Issuer, must match issuer in the auth config.
    realm: 'https://docker.cdot.systems/auth' # Our auth path
    service: 'Docker registry'
    rootcertbundle: /etc/letsencrypt/live/docker.cdot.systems/fullchain.pem # TLS Certificate

After with the help of @humphd we added our docker_auth in our docker-compose.yml.

  docker_auth:
    image: cesanta/docker_auth
    volumes:
      - ./config/docker_auth:/config:ro
      - /var/log/docker_auth:/logs
      - /etc/letsencrypt:/etc/letsencrypt
    command: /config/auth_config.yml
    restart: always

I also had to look at the issue created in docker_auth repo to see if someone showed some steps to setup docker_auth under nginx. Thankfully to this https://github.com/cesanta/docker_auth/issues/184. I was able to setup nginx for docker_auth.
I just have to add this under our nginx.conf

    location /auth {
      proxy_pass                          https://docker_auth:5001/auth;
      proxy_ssl_trusted_certificate       /etc/letsencrypt/live/docker.cdot.systems/fullchain.pem;
      proxy_set_header  Host              $http_host;   # required for docker client's sake
      proxy_set_header  X-Real-IP         $remote_addr; # pass on real client's IP
      proxy_set_header  X-Forwarded-For   $proxy_add_x_forwarded_for;
      proxy_set_header  X-Forwarded-Proto $scheme;
      proxy_read_timeout                  900;
    }

To test if that works. I had a call with @humphd to test directly in the server at the same time fix stuff that wasn't working.

In issues, I wasn't the only one contributing to it. With the help of @humphd and @TDDR, we were able to implement this feature.