Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.


Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Bookmarks
  • Search
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo

Cloudron Forum

Apps | Demo | Docs | Install
  1. Cloudron Forum
  2. Feature Requests
  3. Security: restrict access to cloudron apps

Security: restrict access to cloudron apps

Scheduled Pinned Locked Moved Feature Requests
3 Posts 2 Posters 516 Views 6 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • potemkin_aiP Offline
    potemkin_aiP Offline
    potemkin_ai
    wrote on last edited by
    #1

    I'm pretty sure that was raised earlier, but I didn't manage to find a dedicated post on that, so here it is.

    Please, let me token/network protect my endpoints / applications.

    Use cases:

    • I have a public facing site with CMS - I really don't want to offer extra attack angle by exposing that I'm running Cloudron and offering dashboard access to anyone at all - yes, I know about two factor auth, but it still relies on Cloudron code reliability - with all respect, we are all just a human beings;
    • Cloudron health-check API endpoint expose a way too much information for actually anyone:
    {
      "version": "7.4.3",
      "apiServerOrigin": "https://api.cloudron.io",
      "webServerOrigin": "https://cloudron.io",
      "cloudronName": "<...> Workspace",
      "footer": "<...>.",
      "adminFqdn": "<...>",
      "language": "en",
      "activated": true,
      "provider": "generic",
      "setup": {
        "active": false,
        "message": "",
        "errorMessage": null
      },
      "restore": {
        "active": false,
        "message": "",
        "errorMessage": null
      }
    }
    

    I did nothing, but I've already got a lot of information: what admin decided to put in footer (could be not innocent), what is a provider, setup flags, language, exact software version.

    Same is pretty much for a lot of other helpful services and .well-known folder (especially for Matrix's Element), but not to be exposed wide open.

    If that's not possible, for whatever reason, is there a way to disable an SSL on Cloudron, so that I could setup my own reverse proxy to take care of all that?
    I mean - it's really really not secure.

    Protecting access via IP range and/or password/some token doesn't seem to be complicated, as it offers me a way to control who have access.

    For example, for the health-check, shall it be as verbose as it is now, I would limit 127.0.0.1 access; for many of the services - security gateway only access; etc.

    girishG 1 Reply Last reply
    3
    • potemkin_aiP potemkin_ai

      I'm pretty sure that was raised earlier, but I didn't manage to find a dedicated post on that, so here it is.

      Please, let me token/network protect my endpoints / applications.

      Use cases:

      • I have a public facing site with CMS - I really don't want to offer extra attack angle by exposing that I'm running Cloudron and offering dashboard access to anyone at all - yes, I know about two factor auth, but it still relies on Cloudron code reliability - with all respect, we are all just a human beings;
      • Cloudron health-check API endpoint expose a way too much information for actually anyone:
      {
        "version": "7.4.3",
        "apiServerOrigin": "https://api.cloudron.io",
        "webServerOrigin": "https://cloudron.io",
        "cloudronName": "<...> Workspace",
        "footer": "<...>.",
        "adminFqdn": "<...>",
        "language": "en",
        "activated": true,
        "provider": "generic",
        "setup": {
          "active": false,
          "message": "",
          "errorMessage": null
        },
        "restore": {
          "active": false,
          "message": "",
          "errorMessage": null
        }
      }
      

      I did nothing, but I've already got a lot of information: what admin decided to put in footer (could be not innocent), what is a provider, setup flags, language, exact software version.

      Same is pretty much for a lot of other helpful services and .well-known folder (especially for Matrix's Element), but not to be exposed wide open.

      If that's not possible, for whatever reason, is there a way to disable an SSL on Cloudron, so that I could setup my own reverse proxy to take care of all that?
      I mean - it's really really not secure.

      Protecting access via IP range and/or password/some token doesn't seem to be complicated, as it offers me a way to control who have access.

      For example, for the health-check, shall it be as verbose as it is now, I would limit 127.0.0.1 access; for many of the services - security gateway only access; etc.

      girishG Offline
      girishG Offline
      girish
      Staff
      wrote on last edited by
      #2

      @potemkin_ai said in Security: restrict access to cloudron apps:

      I did nothing, but I've already got a lot of information: what admin decided to put in footer

      The footer is actually used in the login screen (in 7.5.1) . It's not a place to put some private information.

      I agree with restricting access to dashboard/apps though.

      potemkin_aiP 1 Reply Last reply
      1
      • girishG girish

        @potemkin_ai said in Security: restrict access to cloudron apps:

        I did nothing, but I've already got a lot of information: what admin decided to put in footer

        The footer is actually used in the login screen (in 7.5.1) . It's not a place to put some private information.

        I agree with restricting access to dashboard/apps though.

        potemkin_aiP Offline
        potemkin_aiP Offline
        potemkin_ai
        wrote on last edited by
        #3

        @girish

        The footer is actually used in the login screen (in 7.5.1) . It's not a place to put some private information.

        Probably, it's worth to mention that at the customization page?

        I agree with restricting access to dashboard/apps though.

        Glad to hear that! Do you believe that could make it to the roadmap anytime soon?

        1 Reply Last reply
        2
        Reply
        • Reply as topic
        Log in to reply
        • Oldest to Newest
        • Newest to Oldest
        • Most Votes


        • Login

        • Don't have an account? Register

        • Login or register to search.
        • First post
          Last post
        0
        • Categories
        • Recent
        • Tags
        • Popular
        • Bookmarks
        • Search