51ºÚÁϲ»´òìÈ

Transcript

All right. The recording is on, Maria. Feel free to start with your presentation.

Hello, everybody. So I Mario’s. And together with, my colleagues, Quentin and, Florian, I will be presenting, an introduction to the 51ºÚÁϲ»´òìÈ managed CDN for Am cloud service. I think this is, our first, gym session on the topic. So we will do first, a general introduction into, the managed DNA for, a m, and, then, present how you can configure it and then deep dive on some, more specific topics, on configuration, like redirects and, traffic protection. And, at the end, we will also have a short demo to, show you how to deploy these configurations. So first let me start with, a little bit of context. We are, part of, the content delivery team for Amazon cloud service. We are dealing mostly with, clean management.

The CDN was introduced for a cloud service, since GA. And roughly speaking, the problems that we are dealing, is, modifying the requests coming in, and the response is going out, routing them, to appropriate origins and, and, caching.

So, I would start, first by asking what you, is useful for. So, typically the seeds were used as, also as, storage, so you could put your binaries in a CDN, but, now the functionality is, going, more towards, reverse proxy. So, it’s not necessarily about putting binaries in the cloud.

You, typically have, a reverse proxy, and one of the most important features of the CDN, it’s actually a crucial, functional, feature, right now is to host your custom domains and certificates. So this is needed to, to actually go live, with, your site, and, it is important to do to host these, certificates and custom domains, in a because, the TLS handshake for, establishing a secure, connection is very influenced by the distance between the browser and the server. So it’s a lot faster if the servers are, closer to, to the actual clients. It’s so, a couple of hundreds of, milliseconds faster.

So it’s always good to have the certificates deployed, as, as near, to the to the actual client. But also another important, feature for performance is caching. So delivering, an Http response from, from cache, it’s actually under ten milliseconds while fetching it from the origin. If it’s not cached and you need to compute, typically it takes hundreds of milliseconds.

So, all these, functionalities can be configured, in a sudden. And, we actually introduced, a lot more, configurability options in the, out of the box CDN for ehm, cloud service.

But, let me first mention that, while we have an out of the box, 51ºÚÁϲ»´òìÈ manage CDN for all of cloud service environments, you can also, do all these customization in your own CD. And so the bring your own CDN pattern is supported. But for cloud service environments, even if you have your own CDN, as it’s shown here in the first diagram, the request will still go through the 51ºÚÁϲ»´òìÈ managed to the end and then to the origin, which is formed from the dispatcher and, a m, for edge delivery sites, if you have your own CDN, you can go directly to a m live. So, it’s not necessarily that you go through the 51ºÚÁϲ»´òìÈ managed CDN.

Even if, strictly speaking, the M live is also, implemented to that, at the edge in a CD.

Okay. But, of course, if you don’t have, your own CDN or you don’t want to use one, you don’t want to pay for an extra CDM, you can use the 51ºÚÁϲ»´òìÈ CDN. And, this is provided for, out of the box for every, cloud service environment.

And, it is between the browser and the dispatcher. But also recently it is provided also for, delivery sites. So you can have, an 51ºÚÁϲ»´òìÈ Manage CDN in front of, an edge delivery site, in front of your Am live, domain. And, you can configure, custom domains and certificates there so you can go live. We finish delivery site entirely using, the 51ºÚÁϲ»´òìÈ offering.

Just to recap, until now, the 51ºÚÁϲ»´òìÈ connection is, always present for cloud service environments, but for, delivery services, is optional if you have your own client. And, main features of, of the CDN are managing, domains and certificates. You can do these for, both of these flavors, for CSS environments and for EDS sites. And also customizing the requests, responses. And, well, this is possible currently for, cloud service environments and soon it will be available or also for as delivery. 51ºÚÁϲ»´òìÈ managed used for delivery.

Now I will, go a little bit, in detail, on the, customization options for the cDNA for, for the 51ºÚÁϲ»´òìÈ, they’ll be mentioned. We are calling this the CD configuration.

And, typically it means, functionality, for transforming the Http requests and, and responses. So we got a lot of, feedback during the, past years that, out of the box cDNA for cloud service is not customizable.

And, in the last year, we introduced a lot of, functionality to allow you to, modify headers directly at the CD, rewrite paths, block traffic, redirect, for your one, for your to redirect. And, a very requested feature was to proxy to external origins. If you have a third party system that you want to integrate to with your, in your, custom domain. So, of course you could do all this header manipulation, proxying, all with the existing stack of cloud service because in the end, a m has an Http server dispatcher is in itself based on Apache and is an Http server. So you could modify all this, in, in the M in an M servlet filter or with new dispatcher directives. But it is a very advantage, advantages to do the modifications, as soon as possible when the request comes in, in into the, infrastructure, for security reasons, if you want to block some requests, it’s good to do it in the outermost layer. But also, if you want to do a rewrite S of FS and normalizing all the query parameters and so on, it’s good to do it as soon as the request enters the infrastructure so that all, all your layers of infrastructure see the same, thing afterwards. So, and, of course, the or manipulating, a request, in M and dispatcher will not work with H delivery services, which, don’t have m nor dispatcher. So, this, way of writing client configurations, it’s, compatible also with delivery services.

So we introduced, a new type of, pipeline, in Cloud Manager.

It’s called the targeted deployment, pipeline of type configuration. In short, we call it, configuration pipeline.

Which, consists of, essentially of a Yaml file. So you can define a, a pipeline to deploy a Yaml file to the, CD.

So you can see the structure you just need in your repo or a folder, a slash config, with a CD dot Yaml, file. And the, and Yaml should look something like, you see below. There are several sections like request transformations, traffic filters, authentication or redirects, or region selectors and response transformations. I will go through, for all of these, next, but first, let me tell you a little bit how how they are executed so that, each of this, phase is, executed in an order. The, the browser makes a request to the CDN, and then the first ones that are executed are the request transformations. Here you can manipulate the request, add remove headers. It’s the exact request that comes from, from the browser. So, unaltered by any of our logic. And then, after, you clean up the request, you can allow or disallow traffic based on a different rules. This is the, WAF part or the web protection part. Quentin will talk more about this in, in this presentation. And then, you can check the, the user or the visitor’s, credentials, in the authentication, phase, ask if the, request should be redirected, and then in the end, select the origin where you would want to send this, request. So this happens all before, after all these phases, you have chosen, an origin, and then the cache is inspected. If, the response already exists in the cache. If it’s not in the cache, the, request goes to the, origin. The M origin or an external one. And then the response comes back and you have the less chance of interacting with the, the response in, in our response transformation. So all these faces right now are configurable and offer pretty much, pretty high degree of, liberty to, to the customers.

I will talk now a little bit about the structure of these CDM rules. As I said before, these are some Yaml, document, and a rule, has, typically a name, a condition and an action. The name is just for debugging. The condition says when the rules should apply. And the action, what the rules should do. The conditions are typically general in all phases. You can write conditions based on, request path, URL method, query string, things like that, or client type client country. So in all phases you can write these conditions using this request properties.

And you can have predicates like who will using the regular expressions or exact match and so on. And then the actions are typically specific to each phase. In the request transformations you can set unset headers into. In traffic filters you will see you can block a lot of requests. So these are typically a specific for each a high level section. You can also have variables. I am naming them here just to have it in mind where you can pass state between, between phases from request transformations to traffic filters. Okay. So next I will go just through, a couple of, these, faces. The first one, as I said, the first one that is executed is the request transformation. Request transformations are very useful to normalize your, your URLs and to sanitize them, and sanitize the request. What does it mean to normalize the URL? So if you have abnormal URLs or for example, your, your site serves only pages without, HTML. Exactly. Extension, you would want to strip the, dot HTML so that, you both request with, HTML and without will hit the same cache key, because the URL is part of the cache key. So typically is a very good tool for also remove query parameters that are not needed again, to maximize the, the cache kids.

You can also sanitize the request headers like, removing authorization header if your site does not need the authorization just to prevent any hacks or, unexpected behavior. So in general, use the request transformations to, to minimize your URL space, avoid cache busting, attacks, and maximize, the, the cache ratio.

Here is the first time you would see, how how a rule looks like this one is, request transformation that matches has a condition or one condition and, it matches if the domain is done by example.com and the path is search, and the action is to unset all the query parameters that are not matching search IDs. So essentially you only allow one query parameter, on to your application removing all the others. You can the second rule is on setting, a request, header. So as I said, these kind of, conditions can be used in all in all rules.

But I will not go through all of these. Some of these will be covered by my colleagues. But from the, previous diagram, you saw that the request then flows through traffic filters, authentication, redirects, and, we also have some handlers for, for errors, error pages.

I will just mention here the authentication, the use case, where we have currently three types of authentication, a supported one is edge key or authentication. This is to integrate your, custom, Sydney, if you have one with the 51ºÚÁϲ»´òìÈ managed client. So only your custom client can connect to the domain, and, but, and I wanted to show here, that you can use secrets in this Yaml files.

You can reference them, secrets that have been previously deployed as environment variables for, for your environments. This is the syntax dollar. Curly brace, curly brace. And then the name of of the secret. You can also set up, punch key. And also we have implementing and implemented the basic authentication that is supposed to be used only for, previewing content or before going live is, I mean, basic author is not, considered a fully fledged authentication mechanism. So we should not replace the, the normal authentication that you are using. We are now investigating to, you know, build integration with, identity providers using OpenID connect. So if you are interested in this, please contact us.

And we can work in an early adopter program, to understand your use case. Okay. So, Now, the next feature I would go through is the origin selectors. This was a very, highly requested feature to proxy requests to different origins.

There are some properties here, but I think I have to rush a little bit through, through the presentation. What’s important is that you can define, an external origin, and then, you can select it for, different parts of your, application. Here is a diagram that shows how, this will look like for proxying some of the requests to, a, cloud service environments with dispatcher in the VM. But the other request, who am alive and, the the definition of such a rule would, would look like this. So the section is origin selectors. You have to define, an origin with a name and, domain and then, for, for the selected paths. So if the path matches, create styles, fonts, you just say the actions should be select origin. And the name of, of the origin. So this way you can proxy to whatever external origin you have including edge delivery sites, response transformations. The last thing that are executed, you can modify response headers and status and they are very useful, if you want to set also response headers for blobs because that’s a tricky, part in the, in a cloud service.

I had here a diagram how the blobs are served, but I will just leave the diagram and mention that if you want to set up custom headers on, blob response, you should use, response transformations. So with that, I conclude my, introduction, and I will hand it over, to Quentin to speak about redirect and, traffic filters.

So thank you. Marius. Yeah, I think you will have to release the screen so I can share it. Sorry for that.

Okay. Thank you. Marius. So now, let’s jump into the topic of traffic redirect. So here I’m, I’m talking about, client side redirect. So the, 301302 redirect. So, as you might already know, usually in IAM as a cloud service, dispatcher is a, right place to handle this kind of redirect. Mainly because dispatcher can handle redirects, ranging from, a few to 10,000 of redirects. So usually, you will use model, right. But she module, in order to handle you client redirects, it will be directly part of you and, project code, which means you will be able to deploy, you redirect through the webchat pipeline or the full stack pipeline.

But, a few weeks ago, we actually released a new way of handling a client, redirecting dispatcher using, pipeline free, your redirects approach, that leverages the exact command redirect manager and gives the ability to your marketing and content team to, to manage, redirect directly from UI. So it means there is no need for, Yeah. Using git. And there is also no need to, execute any pipelines. So it’s quite nice. And we actually wanted to mention also that while redirect still under the dispatcher they can still be catch again, which is quite important. If you, set the proper cache control headers directly from your dispatcher configuration.

But last year, we also introduced, a new client capabilities for you towards you and the clients redirects directly to the client. But it comes with some limitation, especially around the size of the client configuration that you can deploy, which is limited to around 100 kilobyte. So it means you won’t be able to, yeah, basically deploy thousands of redirect that you can. So you should, yeah, keep you the, the usage for like really simple use cases such as, redirecting you up x domain to w w w domain. And here we have an example that you can see. It’s quite easy to use.

You can also use client redirect feature to redirect to canonical you around. So meaning by stripping an extension from the, request to Iran and another, quite useful, use case that you can do as a client is to redirect, you visitor to a country specific page based on the, geolocation, of, of the client IP. So now, let’s dive into another topic, which is traffic protection. So, traffic filter routes was one of the many, new feature we introduced last year. So traffic filter routes enables you to block log and alert traffic, based on patterns directly at the CDN. So it means you can leverage those kind of routes to, for example, block IPS or block, specific set of countries or even logs. Log in the logging attempt on your website. Of course, you can also leverage, traffic filter routes to, block more, more advanced patterns. For example, you can leverage the, the regex, operation, in the routes to route for a scaled keyword, part of the, query string, in order to identify potential screen injection. The same way you can also, inspect, the request path with a regex in order to find the potential attack. And the last example will be, to leverage traffic filter rules to block, a specific extension such as PHP, which is quite useful here because M first of all, is not doing any, any business with PHP. And PHP is also, a common target of vulnerability scanner. So you might want to, to block it so you can use again traffic filter rules to even implement your own, simple WAF. But, you will have to be aware of, limitation. First of all, following like your regex approach to, to block traffic is, is really time consuming because you really have to take a lot of time to nail the regex, but also to look at your traffic to see if there is any, you know, attacker that might found a way to bypass your regex. And there are also some, technical limitations. Not necessarily, introduced by the rules, but more by the underlying script language. As a rule, the rules gets compiled to, which is VCL, for instance, VCL doesn’t let you, doesn’t provide the way for you to iterate through, requested URLs. So it means if you would want to, inspect your, your request for an accesses, exploit, you will have to explicitly, list every request in there to analyze. So it’s not really, scalable. Another big limitation is, the fact that VCL doesn’t let you inspect the body of a request. So same here if you would want to look for any success exploit send video form. Unfortunately, you won’t be able to do it with VCL neither with current traffic filter rules. But for customers that requires like a more advanced security feature. Directly at the end.

51ºÚÁϲ»´òìÈ also has a project called. The aim of that is running directly at the client, and that will offer you more advanced protection against web stock ten to a screen injection accesses, as well as protection against anomaly by being able to identify, traffic coming from those scanners or traffic towards non private files such as environment file, password file, etcetera. And it will also be able to detect traffic coming from known bad actor, also known malicious IPS known malicious but etcetera. So the M WAF is a self-serve product that requires a separate license. It comes directly with, pre-configured set of rules that you can directly enable or disable via the traffic filter rules. So how does it looks like in practice? Here we have an example, as you can see, of a traffic filter rules that you can use to block, or webs to obtain vulnerabilities on your website. So it’s as simple as defining a condition, when stall, which means that you want to always, block, traffic when the traffic is actually flagged as being like in this screen injection or accesses or traversal of attack, etcetera. So as you can see here, there is no more regexes, basically the, the overall logic to inspect, request for malicious, payload is directly enter into the WAF. So you don’t have to worry about that anymore. And it’s also more robust because it was will be able to inspect the entire like request. So both the address and the body. So it’s a huge gain of time. And it’s also, far more robust.

So now that you know about the tools to, best protect, your website, you might wonder, how can I know that I’m even getting attacked? And so for that, 51ºÚÁϲ»´òìÈ provide, tools in several variant that you can use, in order to analyze usage and traffic. So the first document is a Elasticsearch Kibana stack that you can install, locally on your laptop. You can download, you can logs from Cloud Manager, ingest them, and then you will have access to the following dashboard. The second variant is for customers that are leveraging the log forwarding feature to forward their logs to their own, spring instance. So for them, we also provide the spring dashboard that they can, install directly in their own, spring instance. And they will have access to exactly the same level of, of information. So we provide two dashboards. One is really focused on client traffic analysis. It’s the following dashboard where you will get insight on you on you traffic. So you will be able to see top IPS, top curators, top user agent, top countries, as well as the distribution of traffic over time. And, if you have a workflow sense, you will also be able to see, WAF insights from the dashboard. So you will be able to tell, what kind of vulnerabilities attackers are, trying to exploit on your website. So it should give you enough information and enough insights to for you to come up with the right to and traffic filter rules. The second dashboard is more focused on, your website performance in terms of cache ratio and cache coverage. So it will help you identify, potential resources that are node cache that can and that you might want to, look into, and, implement proper dispatcher configurations to improve your cache ratio and therefore the performance of your website. So now that you know about the tools and how you can analyze usage and traffic, let’s dive into a specific kind of attacks. See those attacks? So nowadays, unfortunately any website can be the target of those attacks. And so that’s why, 51ºÚÁϲ»´òìÈ provides some out-of-the-box protections, in order to mitigate the DDoS attack on your website, some of the protections are directly coming from, firstly or client provider that will protect you at the TCP IP level. And on top of that, 51ºÚÁϲ»´òìÈ, who has his own, guidance protection at http level that, mainly relying on the rate limiter. So it means any, Amazon cloud service environment has its own rate limiter, configured directly by 51ºÚÁϲ»´òìÈ, that aims to protect you against really volumetric attacks. And here I’m talking about millions of requests per minute. So if those protection they work without a kicked in. Sorry. You will receive directly an action center notification, to let you know that your website is under attack. But to to be taking the proper actions to mitigate the attack by blocking, the, the malicious traffic, if that ever happened to you, we highly recommend you to download. You can logs and use the dashboard we just showed you in order to better understand, the scale of the attack and maybe find a couple of patterns that you might want to, to block, using client traffic filter rules. And so one way to protect, your website, against those attack using current traffic filter rules is to actually leverage the rake meter feature. So how it looks like, it’s actually quite simple to set up. So, it’s the key part of the client traffic filter rules. You can define the, a rate limit node. And by the way, here we have an example of how you can limit the number of requests per IP. So the rate limit, node is composed of several properties. The first one goes together. So the limit and window, it basically describes the average number of requests per second on the, on the time window for which the rate limiter should kicked in. So in that specific example, we want to start looking at night. If it makes the an average more than 100 requests per second on the ten second time window, the next property penalty defined in seconds. So it’s the number of seconds for which, the IP will get blocked. If it, if you go over the threshold, then we have the group volume, which here is set to request property. Client IP. It basically tells the rating meter how to aggregate the, the data. So basically here we want to block per IP. But if you want to call block per user agent, opera path. And of course you can also combine multiple properties. So if you want to rate limiter to block per client IP and path, you can also do it. The only information here, which is quite important, is that the rate limiter is deployed at Poplarville, in firstly and the final properties count. So we offer free kind of, rate limiter that will count different things. So the first one is count or so it will basically, count every incoming request that you can the second one is fetches, which will count only request, that goes to origin, meaning a request that cannot be saved from, from cache. So misses and passes and the final one will count on the errors. So and by that I mean client side and server side errors. So we highly recommend you to use, the free variant because they will basically protect you, from three different things. For example, the count all will, more protect you content request budget. So if you want to avoid, an IP to make too many, content, request, on your website that might impact your budget. It’s the right ratio meter to to implement. The second one fetches is more to avoid any or to mitigate any potential outage, on you, on your origin. So by blocking IP that are making too many requests, that bypasses the client cache.

And the third one will only count their roles, as I said. And it’s quite useful to, block. Either IP that, client IP that are making to a new request that goes to your origin and that start, over helming like the origin. And so it might be like, you know, early side of, of an outage. So you might want to block that IP, but it’s also quite helpful, to block, scanners, you know, so it’s kind of that are trying to access some random part of your website and that will generate a lot of load on your origin. And like mostly all requests will anyway end up in for, for. So you might want also to block this IP as soon as possible. This example also introduce another feature called the traffic filter rules alert. So basically by setting the alert field and your action, set it to true, you will be able to receive an action Center notification, once you, traffic filter routes get triggered. So it’s quite helpful to, to be aware of that. Your website is under attack.

Okay. So, the question we often get task is what should be the limit, for, for my reply meter. And it’s a tricky question. And to be frank with you, we don’t really have the the answer because it depends so much on your website and on your expectation. But one thing we recommend you to do is to actually, look at the dashboard. We, we already mentioned, because they contain some information such as, the maximum number of requests per second and power IP, both at the CDN and at the origin. And so if you use those, those graph, you will be able to get the quite accurate value of, what is the limit as of today. And and I would recommend you to start from, from, from those values basically.

So we also wanted to take the opportunity, to share a couple of tips with you, to better protect your website against, potential DDoS attacks. And so the first tip is to always ensure fast responses from origins.

So try to avoid, having response that takes, I don’t know, 30s or 60s to generate. Because it can be seen as a vulnerability from the point of view of an attacker. Basically, the attacker will have to send a really, low amount of, of requests toward that endpoint, and it might already overwhelm, your origin and create a node age. So we’ll try to avoid that. The second tip is to always leverage good caching, simply because the CDN can scale much better than your region. So if you can, server attack directly from the cache, it means no damage because your region, won’t receive that much traffic. And so one good way to actually, leverage good caching is to remove, and don’t query parameters, simply to avoid, you know, cache bursting attacks. So where attackers would send a lot of requests that will bypass the client cache by injecting some random query parameter.

The next tip is to, use a dashboard because as I mentioned, you will find really valuable insights such as the, inaccurate value for your regular meter. Next, try to use different strategies. So as I said, we have, for example, several, rate meters that you can combine to, to protect you from different things. But you can also combine, the same rating meter for different purpose. So, for example, if your website is only doing business in the country, such as, Switzerland, you might want to, to have two rate limiters. One, that will basically only request coming from client IP based in Switzerland, and a second rate limiter with a much strict limit, that come to, request coming from a client IP outside of Switzerland. Next, don’t forget to set up an alert, in order to get notified when the, site is under attack. It’s the best way, to to to know about it. Otherwise, you you might end up with an outage, which is not really nice. And finally, more like a development tip. So client traffic filter rules are quite powerful. And so, you you want to ensure that you test, them. Well, and so for that, I will recommend to always start with, action log, deploy your rule, test it. And if it works, as you expect, then you can Tony, Tony, tell him to blog. So with that, I will hand over to, to Florian for a quick demo. Thank you. Quentin. So for the demo, what I’ve done, I have, like, a normal, regular the environment that is set up, I use the weekend, example site that, you know, from many other Am demos already. Currently there are no rules, conflict here, but we want what we actually want to do is we want to deploy, a couple of traffic filter rules that Quentin has also mentioned before and redirects as well.

That, will offer like a redirect, at CDN level. So what we want to do here is we want to block a path because it’s easier for the sake of this demo to block a path rather than IPS or a specific countries here. But you can block on many different request properties. As mentioned before, already. So on this, the environment, let’s check the status of this one.

Okay. Great.

This is our environment. So let’s actually then, use the new, the deployment type environment config to deploy this configuration. So this is, regular deployment type, similar to what you might know already from the, the how to deploy dispatcher configuration, for example. This one is using a similar mechanism that, you know, from the, configuration pipeline from cloud manager, from the regular dev stage and production environments. Except this one is, uploading the zip configuration, immediately. And you don’t have to upload anything to, you can’t manage to get, installation, initially. So the, first one actually fails, because we have a typo in the configuration. This one I did in order to show you also like the reaction time and the response time on how quick you can actually develop with this. The mechanism. And hopefully you can get actually some feedback on if your configuration has folks typos or, syntax errors.

So now once we fixed, this type of here, this configuration will be uploaded, and another, kind of a use case, for example, that you would have for the redirect, as Quentin already mentioned, you would configure here, redirects from example for your domain, to the setup also especially for country specific domains. For example, if you were coming from the US, you want to have your customers forwarded to the US English website, if you’re, if they’re coming from Spain or Germany to the respective other country websites, as you see here, the configuration has already been deployed to this one. To the KDM. But this does not necessarily mean that it’s already available, because this means that the configuration has been deployed to fastly. But, firstly has a global system and firstly you need to it’s themselves. They need to deploy it to there are multiple different pops. So this might take a couple of minutes sometimes. So as we see here now the adventures page is blocked.

Is basically expected here. And we can also test out the redirect that we had. Configured in the about page here. And this one redirects back to the, English US about page.

So now let’s try out a different scenario that we want to see. We don’t want to have this, traffic filter rule anymore. We don’t want to block it. But instead of blocking, we want to have authentication, and we want to, use some simple basic off to protect, our website from the public traffic, but so that we can, use it as well. And we also want to try out the, origin selector features that, proxies traffic, from the path, everything that is on our example, we want to, proxy to example that com domain, this might be some API of yours, etc… As Marius mentioned you can also define API keys, etc. if you have a protected endpoint, there.

So let’s deploy this one here. I would just like leave it here and show you actually, what’s going on here when it’s deploying.

And if you have any questions, please continue asking in the, question and answers, continue answering and, yeah, posing your questions in the Q&A section of the jam session.

An example here. This will be the page where it will be available, soon. So this is a for for still, as we see here. Now, this one completed. So it takes roughly, like a minute for the, the configuration to be installed in the CDN and then a couple of more, seconds, two minutes until we can see it here. And here we can see the example. The main, is not available under, example. And when we now go actually on the adventures page in a new tab here, then we see also this page is not protected, by a basic graph. So, we can actually see I think I forgot to show you this one here. So the way you define it here is, the defining credential, the as John, for example. And the password is Marius already mentioned. You can define secrets here. That is. So this is an environment variable that is defined in in Cloud Manager. And yeah. As you can see here, this is normally reachable. Now again, the site, the environment variables are defined in Cloud Manager here in the configuration. One important detail to mention. You can have to actually select the type secret. And also you have to select the service also. That that is not specifically, for the service also or published, but that is for all. And that way for the also deployed to the CDM.

That’s it from the demo side here. If you have any feedback to this session or also, just questions about the usage and features features that were presented, or you have other side end use case use cases that you want to discuss with us that you think might not be possible currently. With a CDM configuration, please reach out to us. We also looking into, writing more, more advanced business logic directly at the CDN using edge compute and, JavaScript. So if you have any interest or use cases, please, reach out. And the email is not, noted here. Or you can also reach out in the Q&A, chat. And, Brian will be happy to be in contact with you.

And should we do some Q&A at the end? Yeah. Great. Thanks a lot for your presentation and demo. Before we go into the Q&A, I would quickly like to ask you to complete a, concluding poll. I would post in the general chat.

And then we’re going to switch to Q&A.

And the concluding poll, there’s a question about, that we’re going to the and you can read this session and also post requests for future sessions, what kind of topics you’re interested in and looking forward to, to have in an Am jam session. All right. Let’s look at the questions that haven’t been answered already. Also, thanks to the team for answering this many questions. Again.

All right. Good amount of information is available in this Q&A. Is it possible? Okay. We will post the Q&A, along with the slides and the recording on the contextual thread, you will find the link to the contextual thread in the general chat. We will post this information about 1 or 2 days after the session.

Next question is will it deploy the CD and changes to an author CD and as well as or only publish CDM? This has just been answered by Marius, I see.

In the interest. Yes, I can repeat it. So because it’s a general good practice and I didn’t mention it.

The CD applies to the whole, environment.

So if you block all traffic and you write will a condition that is always true, it will block traffic to author, publish or preview. So it’s always good, to guard your rules, with, with, a condition that, for example, request property tier equals publish. This will apply only to publish or, even better, to request property domain equals your specific domain that you want to apply the rules for.

So yeah. Thank you. Marius. The next question is about, if we share the deck. Yes, we will post the slides along with the recording and the Q&A. 1 or 2 days post session into the, contextual thread. All right. Let me find the questions we haven’t answered. Oh, how can we increase the number of connections if we you are using advanced networking? Advanced networking is for egress traffic. So traffic going from a VM towards other, services. So I don’t it doesn’t go through the CDM. So I don’t think it’s related to this video.

Okay. Otherwise please specify question on traffic rule. If we are blocking request based on IP range and tier as published, does this block custom domains request customer set up domain which will internally get data from publish part as well? Or does it only block when users try to access publish instance directly? This is needed to block direct publish instance from external traffic.

So yeah, go ahead with. Yeah. I mean it’s kind of similar question as just answered. So actually you can leverage the, current rules conditions to really, apply rule for. Yes, read specific conditions. So here, if I, if I read it correctly, you might need a condition with, that apply for privilege here.

When the IPS in the IP ranges that you want to block and, the last conditions will be the domain. So you can also apply, routes, on domains if you want. So if you domains is example.com etcetera. So yeah. Yeah I think those so three conditions put together should should address your use case without blocking the custom domains.

Thank you Quentin. Next question. Does rate limiting it require WAF license? No, it’s part of the CDE and rules, and, so it’s available for the for for any, I’m, I’m a, as a cloud service customer. All right. Thank you. Utilizing sling dynamic include and am set up to handle edge side includes for dynamic content delivery with yes I include is it possible to read the query parameters of the parent URL or appends the parent URL query parameters to the include URL.

No, I don’t think so. So yes, I support is pretty limited. It only has includes and the mode my thing. That’s basically it. So you cannot. Manipulate. The query string. Pass it. I would have to read the question more. But I would say in general the support is pretty basic only for the standard include.

Yeah, we can follow up, post session when we post the Q&A to the contextual thread there, we will specify, where at the top of the I want to take one last question. In case of custom Syrian with two cdms not caused performance issues.

We haven’t seen any, it’s, mostly I would say that, typically the clients are very, distributed basically in the same regions or all the CDN providers and, the latency between their servers, is, is very low. So we have a lot of customers using the, the bring your own CDN pattern and, and there is no latency problem. Okay. Great. Thanks for answering all the questions and a thanks to the audience for all the questions. That is important. So we know, what are your challenges and and where we can improve. I will post the contextual thread link again. So you will be able to check on the recording. Let’s live in 1 or 2 days position. Then I also want to thank you for your attention and for joining and, please stay tuned for any upcoming AMM jams and, join me there in the upcoming webinars. Thank you very much and all. Have a great day or evening. Bye bye.

All right.