Open elliot opened 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?
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.
Need custom domain too
This is definitely something we need as well
Any progress on this topic @mhausenblas ?
No updates at this point in time @barthel
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.
@mhausenblas, @mahmoud-hafez-aws Combined with #26, this issue becomes a blocker in our organization.
Any progress on this topic @mhausenblas ?
@mengdic can you comment on that please?
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.
Hi, any update for this feature? We are still waiting for this feature as there is no another solution than redirect.
this would be a feature we are interested jn as well.
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
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.
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. 😞
+1 for this, we'd love to make custom URLs for our workspace so we can treat them as a trusted internal domain
+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.
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:
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
Thank you for looking into it!
- 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.
- 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.
- 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.
- 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)
- 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
- 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
- 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
- Any other requirements, feedback or concerns you have around this feature?
I don't think so
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).
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)?
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.
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.
Any updates on this ?
+1 for this, would love this feature. would be extremely beneficial.
+1 for this, we'd love to make custom URLs for our workspace
+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.
+1 we have 4 different workspaces. I'm getting loads of complaints.
@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
+1
+1 for this, we would love to create custom domains too
+1
+1
+1
+1
+1
+1
@mengdic Can we have some feedback on what's happening, please? It's been 9 months since you asked for responses.
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.
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.
+2 years later, still waiting for this.
Has anyone already tried putting a proxy (e.g. nginx) in front of the instance that terminates the TLS for your custom domain name?
+1
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
Bump?
+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)
Having to wait for years for something that should have been part of the initial release. What a joke...
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.
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.
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