aws / amazon-managed-grafana-roadmap

Amazon Managed Grafana Roadmap
Other
60 stars 4 forks source link

Support for Custom Domains #6

Open elliot opened 2 years ago

elliot commented 2 years ago

Hi team,

We'd love the ability to give our Grafana instance a friendly alias on a custom domain (e.g. grafana.example.com). Would this be something on the roadmap?

Cheers

mhausenblas commented 2 years ago

Thanks for raising this feature request @elliot and custom domains sounds like something you're in good company to ask for, indeed. In this context: is your ask specifically (only) custom domains or were you thinking about other customizations/branding as well? Would be interested to learn more, if you can share?

williamhargrove commented 2 years ago

I would like to give a thumbs for this feature request as we would like this functionality. I have channelled this feedback via our AWS account manager. From my point of view it would be useful to be able to customise both the URL and have some ability to add organisational branding to the interface.

Currently we have an HTTP redirect workaround in place - but this is not optimal.

Larzack commented 2 years ago

Need custom domain too

gilliu00 commented 2 years ago

This is definitely something we need as well

barthel commented 2 years ago

Any progress on this topic @mhausenblas ?

mhausenblas commented 2 years ago

No updates at this point in time @barthel

barthel commented 2 years ago

The issue is so important, especially when SSO SAML must be used.

As soon as the Grafana Workspace has to be rebuilt, the SSO SAML configuration has to be adjusted manually as well.

I would like to see the concept based on the already existing custom endpoint concept of AWS OpenSearch domains.

barthel commented 2 years ago

@mhausenblas, @mahmoud-hafez-aws Combined with #26, this issue becomes a blocker in our organization.

barthel commented 1 year ago

Any progress on this topic @mhausenblas ?

mhausenblas commented 1 year ago

@mengdic can you comment on that please?

sherifabdlnaby commented 1 year ago

This feature should be essential for such a service, as someone who cares about Developer Experience, having such a random URL for our Grafana is a horrible experience. Yes, redirects make it a bit better, but ideally, we should be able to have a custom domain set up.

jandominik commented 1 year ago

Hi, any update for this feature? We are still waiting for this feature as there is no another solution than redirect.

robtdlt commented 1 year ago

this would be a feature we are interested jn as well.

donkee commented 1 year ago

We are also interested in this feature. Tried setting up a CNAME record in Route53 and it isn't working. I'm guessing it's due to a cert mismatch

EliTayrien commented 1 year ago

We are also interested in this feature for the reasons listed above: the random URL is quite confusing, especially when IaC changes to the workspace cause it to be rebuilt. Our primary need is for a custom domain, and we don't really need custom branding/etc. If branding were available, we'd probably use it to put headers on the page for dev/stage/prod to make them easier to tell apart.

hastarin commented 1 year ago

We were all ready to start using this. We'd even gone to the trouble of testing we could get SSO working, and SAML integration with Auth0, but this is a deal breaker, and we'll need to go with Grafana Cloud instead. 😞

JamieB101 commented 1 year ago

+1 for this, we'd love to make custom URLs for our workspace so we can treat them as a trusted internal domain

matiri132 commented 1 year ago

+1 for this, i have a few customers where i want to start using this service and without a custom domain it would be a problem.

mengdic commented 1 year ago

Hello all,

Currently, our team is in discovery and design phase where I would like to collect your feedback and use cases for this feature.

Could you please share:

  1. Your use cases, and how would this feature help you/your organization? How critical is this feature (e.g. for the orgs who uses AMG as a service provider, does this feature blocks your org to on board more users/customers in AMG)?
  2. For the ones who would like to improve your SAML experience, do you have a strong preference to have your SAML to work with the new custom domain or the canonical domain under the hood?
  3. If you are planning to use the custom URL for SAML, are you aware that you may also need to reconfigure the user authentication (e.g. reconfigure SAML IdP)? If so, do you have any concerns?
  4. Any other requirements, feedback or concerns you have around this feature?

To participate in this use cases collection, please reply directly to this thread. Alternatively, if you prefer a more private channel, feel free to direct message us or send your responses via email to aws-grafana-feedback@amazon.com.

Thank you, Mengdi Chen Sr. Technical Product Manager, Amazon Managed Grafana

kpmueller commented 1 year ago

Thank you for looking into it!

  1. Your use cases, and how would this feature help you/your organization? How critical is this feature (e.g. for the orgs who uses AMG as a service provider, does this feature blocks your org to on board more users/customers in AMG)?

Our use case is to avoid having to manage (terraform), or try and remember or link to opaque AMG urls. Because they are essentially opaque, there are opportunities to have errors or confusion.

It isn't essential, but it's definitely a negative in comparing using AMG vs our own Grafana.

  1. For the ones who would like to improve your SAML experience, do you have a strong preference to have your SAML to work with the new custom domain or the canonical domain under the hood?

It would be nice if it could work with both (through separate SSO apps), but the custom domain would be preferred.

  1. If you are planning to use the custom URL for SAML, are you aware that you may also need to reconfigure the user authentication (e.g. reconfigure SAML IdP)? If so, do you have any concerns?

It shouldn't require a lot of work, but it would require some. I don't think it would be a concern unless it worked in a weird way, or unexpected way. If it had to change when enabling the custom domain, that's fine.

  1. Any other requirements, feedback or concerns you have around this feature?

Assuming that it's a configuration you enable, my only concern would be that it works in an unexpected way.

For example, if enabling a custom domain broke existing authentication, or the existing URL, without a notification that only one URL or SAML domain works at a time. (if that were true -- ideally it will work through both)

donkee commented 1 year ago
  1. Your use cases, and how would this feature help you/your organization? How critical is this feature (e.g. for the orgs who uses AMG as a service provider, does this feature blocks your org to on board more users/customers in AMG)?

Mainly it would just be easier to remember the URL if we could make it something simple like grafana.mydomain.com. It is non-blocking, purely a nicety for us

  1. For the ones who would like to improve your SAML experience, do you have a strong preference to have your SAML to work with the new custom domain or the canonical domain under the hood?

I'm not sure which I would prefer, as long as the customer experience is the same

  1. If you are planning to use the custom URL for SAML, are you aware that you may also need to reconfigure the user authentication (e.g. reconfigure SAML IdP)? If so, do you have any concerns?

I'm fine with reconfiguring that

  1. Any other requirements, feedback or concerns you have around this feature?

I don't think so

raymalt commented 1 year ago

Hello all,

We are actively working on pulling this feature into AMG. Currently, our team is in discovery and design phase where I would like to collect your feedback and use cases for this feature.

Could you please share:

1. Your use cases, and how would this feature help you/your organization? How critical is this feature (e.g. for the orgs who uses AMG as a service provider, does this feature blocks your org to on board more users/customers in AMG)?

This is a blocker for us, since the end customers expect a custom domain name. Grafana Cloud currently supports it and this needs to be in place before a switch-over to AWS Managed Grafana (which would be convenient for other reasons).

petersmol commented 1 year ago

That's excellent news @mengdic!

Your use cases, and how would this feature help you/your organization? How critical is this feature (e.g. for the orgs who uses AMG as a service provider, does this feature blocks your org to on board more users/customers in AMG)?

  1. Memorisable grafana url
  2. Permanent links in the documentation that will work after migration to another workspace/aws account

Currently we use http redirects and it's quite annoying (we cannot use the proxy because it breaks SAML). We can tolerate default urls for some time, but it will block migration to new AMG instance as we onboard some hundreds teams.

For the ones who would like to improve your SAML experience, do you have a strong preference to have your SAML to work with the new custom domain or the canonical domain under the hood? If you are planning to use the custom URL for SAML, are you aware that you may also need to reconfigure the user authentication (e.g. reconfigure SAML IdP)? If so, do you have any concerns?

No strong preference as long as customer experience is the same. Basically we want everybody to see "pretty" urls in browser and documentation, and don't care much about what's going on under the hood.

robtdlt commented 1 year ago

Hi @mengdic, Thanks for this. Our primary purpose for having the CNAME is to allow us to open up our Grafana to more of our users, we currently use a WAF firewall that has IP whitelisting by to resources under our Domain., if we can use the CNAME we can allow access to the dashboards for our user base.

The other major benefit is a simpler URL to access our Grafana Dashboards.

Samia2Aimas commented 1 year ago

Any updates on this ?

colinbut commented 1 year ago

+1 for this, would love this feature. would be extremely beneficial.

matiaszilli commented 1 year ago

+1 for this, we'd love to make custom URLs for our workspace

andrewbcoyle commented 1 year ago

+1 from me as well. Use cases: • Upgrading Grafana versions -> No need to update all pipelines, documentation links, etc. • User/customer friendly URL's are slick • "Shortened" URL's could actually be short.

adamlowerycc commented 1 year ago

+1 we have 4 different workspaces. I'm getting loads of complaints.

preetmyob commented 1 year ago

@mengdic

+1 I too would like to to see this please

Your use cases, and how would this feature help you/your organization? How critical is this feature (e.g. for the orgs who uses AMG as a service provider, does this feature blocks your org to on board more users/customers in AMG)?

We use on prem grafana to monitor the EC2/OS stats of hundreds of servers hosting thousands of enterprise level customer applications. We use Route53 through an ACM for this on service/other services. We would like to migrate to AMG and continue to use our existing wildcard certificates. At this point the lack of ability to provide this simpler URL really is a blocker for us. We likely to be growing our customer base by thousands over the next few years and consequently we'll be collecting and monitoring a tonne more data, and would prefer to managed the grafana instance centrally through our AWS operations.

If you are planning to use the custom URL for SAML, are you aware that you may also need to reconfigure the user authentication (e.g. reconfigure SAML IdP)? If so, do you have any concerns?

We already have ACM provided certificates for our on prem and AWS services that allow us to provide simple URLs to our community. We have no issue configuring the SAML IdP if need be.

Any other requirements, feedback or concerns you have around this feature? No

lowkasen commented 1 year ago

+1

Kai-Herzig-VW commented 1 year ago

+1 for this, we would love to create custom domains too

anton-tokarev-softeq commented 1 year ago

+1

gregtayl commented 12 months ago

+1

triclambert commented 11 months ago

+1

alexispetalas commented 9 months ago

+1

liusongdu commented 9 months ago

+1

MarcoFranchin96 commented 8 months ago

+1

preetmyob commented 8 months ago

@mengdic Can we have some feedback on what's happening, please? It's been 9 months since you asked for responses.

tyler-hc commented 8 months ago

Also looking for this to be added.

1) We're looking to move to AMG, but without this it's hard to justify the change. Users want an easy to remember URL or they just won't use it. 2) Working with SAML would be ideal, but whatever allows for a simple URL works. 3) No problems with reconfiguring the SAML.

Kai-Herzig-VW commented 8 months ago

Besides the obvious necessity of creating a custom domain, we built a workaround to give our users an easy to remember URL like @tyler-hc mentioned:

Obviously this solution is not great and adds unnecessary complexitiy, but it works for now.

aalanzhao commented 4 months ago

+2 years later, still waiting for this.

sjoukedv commented 3 months ago

Has anyone already tried putting a proxy (e.g. nginx) in front of the instance that terminates the TLS for your custom domain name?

victor-hugo-chimenez commented 3 months ago

+1

bartenew commented 3 months ago

Has anyone already tried putting a proxy (e.g. nginx) in front of the instance that terminates the TLS for your custom domain name?

Cloudfront works (has issues with SAML auth), but putting NGINX in front of AWS Managed Grafana seems to defeat the purpose of it. I might as well deploy my own Grafana on EKS/ECS

mpasley-cohere commented 1 month ago

Bump?

trinh-tien-dat commented 1 month ago

+1, I would love to have this feature

I have a temporary fix for it, want to share with you, it's not good enough but engineers don't need to remember the workspace url.

Route53 (my-monitor.mydomain.com) --> CloudFront + SSL --> S3 (Enabled static hosting + Redirect to Grafana workspace url)

szymon-zgola commented 1 month ago

Having to wait for years for something that should have been part of the initial release. What a joke...

trinh-tien-dat commented 1 month ago

Having to wait for years for something that should have been part of the initial release. What a joke...

I guess, not much people current using this service, so they don't put much efforts on it.

szymon-zgola commented 1 month ago

Having to wait for years for something that should have been part of the initial release. What a joke...

I guess, not much people current using this service, so they don't put much efforts on it.

I would guess that 90% of people are not using it because this ugly DNS is a deal breaker.