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
  • Brite
  • 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 - Status | 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 968 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

        Hello! It looks like you're interested in this conversation, but you don't have an account yet.

        Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.

        With your input, this post could be even better 💗

        Register Login
        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