18 Jul 2023
In this video, we explore how to take observability to the next level with the Gloo Platform and Grafana. The Gloo Platform already provides powerful observability capabilities through its UI, but with Grafana, we can unlock even more potential.
By collecting metrics using the OpenTelemetry collector on each cluster and forwarding them to the management cluster, we can effectively monitor the behavior of the Gloo Platform. But that's not all - we'll show you how to configure Grafana to build custom dashboards and set up alerts, ensuring the platform behaves at its best.
If you want to take your observability game to the next level and ensure smooth operation of the Gloo Platform, this tutorial is a must-watch. Learn how to use Grafana to gain deeper insights, set up alerts, and monitor the health of the Gloo Platform like never before. Don't forget to like, subscribe, and hit the notification bell to stay updated with more exciting tutorials and demos. Happy monitoring!
By collecting metrics using the OpenTelemetry collector on each cluster and forwarding them to the management cluster, we can effectively monitor the behavior of the Gloo Platform. But that's not all - we'll show you how to configure Grafana to build custom dashboards and set up alerts, ensuring the platform behaves at its best.
If you want to take your observability game to the next level and ensure smooth operation of the Gloo Platform, this tutorial is a must-watch. Learn how to use Grafana to gain deeper insights, set up alerts, and monitor the health of the Gloo Platform like never before. Don't forget to like, subscribe, and hit the notification bell to stay updated with more exciting tutorials and demos. Happy monitoring!
- 1 participant
- 8 minutes
18 Jul 2023
In this tutorial, we'll show you how to expose a product page service through a virtual gateway using the powerful combination of Gloo Mesh and Istio. The virtual gateway allows us to consolidate multiple clusters and efficiently manage services across various environments.
First, we create the virtual gateway, which is translated into the corresponding Istio Gateway object by Gloo Mesh. We select the Ingress Gateway of cluster one and configure it to listen on Port 80 for incoming traffic. Keep in mind that you can have a virtual gateway composed of multiple gateways from different clusters if you need to expose the same service in multiple clusters.
Routing delegation is another key feature of the virtual gateway. We demonstrate two approaches: allowing any route table to be attached or defining specific rules for delegating domains to corresponding workspaces. This enables fine-grained control over different paths, catering to the requirements of various teams.
Additionally, we showcase creating a route table in the same Istio gateway's namespace. The Gateway team can attach their route table to the virtual gateway, specifying paths that will be used by different teams. For example, you can delegate specific prefixes, ensuring clear separation of resources.
Next, we demonstrate how the bookinfo team creates a sub-route table with more granularity. They can define matches for '/product page' requests, '/static' resources, or any other paths required to access the product page service.
Gloo Mesh efficiently translates all configurations into corresponding Istio resources, creating the Istio Gateway resource to listen on Port 80, along with the Ingress Gateway, and a virtual service with defined matches.
While we currently access applications through HTTP, we understand that secure communication is crucial. Hence, we proceed to create a self-signed certificate (please note that in production, proper certificates should be used). You can also automate this process using tools like Vault or cert manager.
With the self-signed certificate in place, we update the virtual gateway configuration to listen on HTTPS (Port 443) and enable HTTP-to-HTTPS redirection. This ensures all traffic is secure and redirects users to the HTTPS version even if they try to access the HTTP version.
Join us in this tutorial to master the art of exposing services through virtual gateways with Gloo Mesh and Istio. It's a powerful approach to efficiently manage services in distributed and scalable applications. Don't forget to subscribe to our channel for more exciting tutorials on modern infrastructure technologies!
First, we create the virtual gateway, which is translated into the corresponding Istio Gateway object by Gloo Mesh. We select the Ingress Gateway of cluster one and configure it to listen on Port 80 for incoming traffic. Keep in mind that you can have a virtual gateway composed of multiple gateways from different clusters if you need to expose the same service in multiple clusters.
Routing delegation is another key feature of the virtual gateway. We demonstrate two approaches: allowing any route table to be attached or defining specific rules for delegating domains to corresponding workspaces. This enables fine-grained control over different paths, catering to the requirements of various teams.
Additionally, we showcase creating a route table in the same Istio gateway's namespace. The Gateway team can attach their route table to the virtual gateway, specifying paths that will be used by different teams. For example, you can delegate specific prefixes, ensuring clear separation of resources.
Next, we demonstrate how the bookinfo team creates a sub-route table with more granularity. They can define matches for '/product page' requests, '/static' resources, or any other paths required to access the product page service.
Gloo Mesh efficiently translates all configurations into corresponding Istio resources, creating the Istio Gateway resource to listen on Port 80, along with the Ingress Gateway, and a virtual service with defined matches.
While we currently access applications through HTTP, we understand that secure communication is crucial. Hence, we proceed to create a self-signed certificate (please note that in production, proper certificates should be used). You can also automate this process using tools like Vault or cert manager.
With the self-signed certificate in place, we update the virtual gateway configuration to listen on HTTPS (Port 443) and enable HTTP-to-HTTPS redirection. This ensures all traffic is secure and redirects users to the HTTPS version even if they try to access the HTTP version.
Join us in this tutorial to master the art of exposing services through virtual gateways with Gloo Mesh and Istio. It's a powerful approach to efficiently manage services in distributed and scalable applications. Don't forget to subscribe to our channel for more exciting tutorials on modern infrastructure technologies!
- 1 participant
- 6 minutes
18 Jul 2023
Are you looking to upgrade your Istio service mesh but unsure of the best approach? In this video, we'll walk you through the two main upgrade methods: In-Place Upgrades and Canary Upgrades. Whether you're running Istio on your own or through the Gloo Platform, this step-by-step guide will help you seamlessly transition to the latest version and ensure a smooth deployment.
🔹 Understanding the Naming Scheme:
Before diving into the upgrade process, we'll explain Istio's version naming scheme. Discover how the major, minor, and patch numbers come into play, and learn how to identify which upgrade method is suitable for your specific version.
🔹 Canary Upgrade: A Safe and Gradual Approach:
The Canary Upgrade is an excellent strategy when moving from one minor version to another (e.g., 1.16 to 1.17). By deploying a second control plane with the new revision and gradually migrating your workloads, you get the opportunity to thoroughly test the new revision before making a complete switch. We'll demonstrate this method using Istio version 1.16.3 and upgrading to version 1.17.
🔹 Leveraging Istio Lifecycle Manager:
Discover how to utilize the Istio Lifecycle Manager to deploy Istio and perform upgrades. We'll walk you through the process of updating the existing applied lifecycle object for your cluster, introducing the new revision tag and version tag in the YAML configuration.
🔹 Deploying New Operators and Gateways:
Learn how to deploy the new operator for the 1.17 revision in a designated namespace using the Gloo Platform. We'll explain how the operators automatically watch the Istio operator resources in the same namespace, ensuring a smooth upgrade process.
🔹 Upgrading Istiod and Workloads:
Follow our instructions to deploy Istiod 1.17 and restart the workloads connected to the old control plane, enabling them to use the new Istiod revision.
🔹 Verifying Application Access:
Ensuring your applications can be accessed correctly during the upgrade is crucial. We'll guide you in testing access to your applications deployed using the Istio Ingress Gateway.
🔹 Updating Gateway and Services:
Discover how to patch the services to target the new Istio revision (1.17) while maintaining the same external IP address, ensuring continuity during the migration.
🔹 Cleaning Up Old Revisions:
Once the Canary Upgrade is successful, we'll show you how to update the lifecycle manager objects to remove all entries related to the old revision (1.16). The Gloo Platform will handle the uninstallation of components associated with the old revision.
🔹 Conclusion:
Upgrading Istio is essential for maintaining a robust and efficient service mesh. With this comprehensive guide, you'll have the knowledge and confidence to perform In-Place or Canary Upgrades smoothly, depending on your Istio version. Watch the video now to master the art of Istio upgrades and optimize your cloud-native infrastructure! Don't forget to subscribe to our channel for more valuable tutorials and updates. Happy upgrading! 🚀🔝
🔹 Understanding the Naming Scheme:
Before diving into the upgrade process, we'll explain Istio's version naming scheme. Discover how the major, minor, and patch numbers come into play, and learn how to identify which upgrade method is suitable for your specific version.
🔹 Canary Upgrade: A Safe and Gradual Approach:
The Canary Upgrade is an excellent strategy when moving from one minor version to another (e.g., 1.16 to 1.17). By deploying a second control plane with the new revision and gradually migrating your workloads, you get the opportunity to thoroughly test the new revision before making a complete switch. We'll demonstrate this method using Istio version 1.16.3 and upgrading to version 1.17.
🔹 Leveraging Istio Lifecycle Manager:
Discover how to utilize the Istio Lifecycle Manager to deploy Istio and perform upgrades. We'll walk you through the process of updating the existing applied lifecycle object for your cluster, introducing the new revision tag and version tag in the YAML configuration.
🔹 Deploying New Operators and Gateways:
Learn how to deploy the new operator for the 1.17 revision in a designated namespace using the Gloo Platform. We'll explain how the operators automatically watch the Istio operator resources in the same namespace, ensuring a smooth upgrade process.
🔹 Upgrading Istiod and Workloads:
Follow our instructions to deploy Istiod 1.17 and restart the workloads connected to the old control plane, enabling them to use the new Istiod revision.
🔹 Verifying Application Access:
Ensuring your applications can be accessed correctly during the upgrade is crucial. We'll guide you in testing access to your applications deployed using the Istio Ingress Gateway.
🔹 Updating Gateway and Services:
Discover how to patch the services to target the new Istio revision (1.17) while maintaining the same external IP address, ensuring continuity during the migration.
🔹 Cleaning Up Old Revisions:
Once the Canary Upgrade is successful, we'll show you how to update the lifecycle manager objects to remove all entries related to the old revision (1.16). The Gloo Platform will handle the uninstallation of components associated with the old revision.
🔹 Conclusion:
Upgrading Istio is essential for maintaining a robust and efficient service mesh. With this comprehensive guide, you'll have the knowledge and confidence to perform In-Place or Canary Upgrades smoothly, depending on your Istio version. Watch the video now to master the art of Istio upgrades and optimize your cloud-native infrastructure! Don't forget to subscribe to our channel for more valuable tutorials and updates. Happy upgrading! 🚀🔝
- 1 participant
- 9 minutes
18 Jul 2023
In this tutorial, we'll walk you through the process of securing the communication to your applications using an OIDC workflow with Gloo Mesh and Keycloak. Whether you're a developer or an IT professional, implementing this workflow will enhance your application's security and ensure only authorized users gain access.
First, we deploy Keycloak as our Identity Provider (IDP) in the cluster. Don't worry if you already have your IDP deployed elsewhere; this guide is adaptable to various IDPs that support OIDC workflows. We'll create two users, "userone@example.com" and "usertwo@solo.io," setting the stage for authorization rules later in the workshop.
Once Keycloak is up and running, we'll configure it to handle user authentication, allowing you to obtain a token from Keycloak as an admin. This token will enable us to automatically create the necessary resources, including the users.
Next, we'll delve into the OIDC workflow by creating an OAuth secret that corresponds with the Keycloak secret. With this in place, we'll implement an extauth policy in Gloo, a powerful tool that applies to routes based on labels. This policy will redirect incoming requests to Keycloak for user authentication. Keycloak will generate an ID token (JOT token), which we'll store in Redis. Instead of storing the token in the user's browser as a cookie, we'll create a more secure approach, using Redis to store the JOT token and a session cookie in the user's browser. This ensures smoother authentication and avoids cookie size limitations.
With the OIDC workflow in place, we'll move on to configuring the extauth server, a vital component in this setup. You can choose to have multiple extauth servers for different teams, but for this demonstration, we'll use a single extauth server for the cluster. This setup allows the extauth server to retrieve the JOT token from Redis on behalf of the user.
Enhancing the security further, we'll use the Open Policy Agent (OPA) Library embedded in the extauth server. With OPA's regal language, we'll define authorization rules based on user email claims. The rules state that if the email claim ends with "@solo.io," the user is authorized; otherwise, access is denied.
After creating the config map to store the authorization rules, we'll update the extauth policies with the new rule, comprising two steps: user authentication and user authorization.
As we wrap up the tutorial, you'll witness the final implementation in action. When trying to access the application, you'll be redirected to Keycloak for authentication. We'll demonstrate successful authentication with user one and user two, showcasing how the authorization rules come into play. If your email matches the authorized domain, access is granted; otherwise, a 403 Forbidden response is generated.
With this comprehensive guide, you'll have a better understanding of securing your application's communication using OIDC workflows with Gloo and Keycloak. Stay tuned for more exciting content and best practices to enhance your application's security and performance. Don't forget to subscribe and hit the notification bell to stay up-to-date with our latest tutorials!
First, we deploy Keycloak as our Identity Provider (IDP) in the cluster. Don't worry if you already have your IDP deployed elsewhere; this guide is adaptable to various IDPs that support OIDC workflows. We'll create two users, "userone@example.com" and "usertwo@solo.io," setting the stage for authorization rules later in the workshop.
Once Keycloak is up and running, we'll configure it to handle user authentication, allowing you to obtain a token from Keycloak as an admin. This token will enable us to automatically create the necessary resources, including the users.
Next, we'll delve into the OIDC workflow by creating an OAuth secret that corresponds with the Keycloak secret. With this in place, we'll implement an extauth policy in Gloo, a powerful tool that applies to routes based on labels. This policy will redirect incoming requests to Keycloak for user authentication. Keycloak will generate an ID token (JOT token), which we'll store in Redis. Instead of storing the token in the user's browser as a cookie, we'll create a more secure approach, using Redis to store the JOT token and a session cookie in the user's browser. This ensures smoother authentication and avoids cookie size limitations.
With the OIDC workflow in place, we'll move on to configuring the extauth server, a vital component in this setup. You can choose to have multiple extauth servers for different teams, but for this demonstration, we'll use a single extauth server for the cluster. This setup allows the extauth server to retrieve the JOT token from Redis on behalf of the user.
Enhancing the security further, we'll use the Open Policy Agent (OPA) Library embedded in the extauth server. With OPA's regal language, we'll define authorization rules based on user email claims. The rules state that if the email claim ends with "@solo.io," the user is authorized; otherwise, access is denied.
After creating the config map to store the authorization rules, we'll update the extauth policies with the new rule, comprising two steps: user authentication and user authorization.
As we wrap up the tutorial, you'll witness the final implementation in action. When trying to access the application, you'll be redirected to Keycloak for authentication. We'll demonstrate successful authentication with user one and user two, showcasing how the authorization rules come into play. If your email matches the authorized domain, access is granted; otherwise, a 403 Forbidden response is generated.
With this comprehensive guide, you'll have a better understanding of securing your application's communication using OIDC workflows with Gloo and Keycloak. Stay tuned for more exciting content and best practices to enhance your application's security and performance. Don't forget to subscribe and hit the notification bell to stay up-to-date with our latest tutorials!
- 1 participant
- 8 minutes
18 Jul 2023
In this video, we explore how to secure the traffic leaving your Kubernetes cluster through an Egress Gateway using Istio and the Gloo Platform. While Istio provides robust features, configuring it for Egress traffic can be complex. That's where the Gloo Platform comes in, making the process easier and more efficient.
We'll show you step-by-step how to:
👉 Automate Egress Gateway Deployment: Just like setting up Ingress Gateways, we'll use the Gateway lifecycle manager to automate the deployment of the Egress Gateway quickly.
👉 Originate TLS Traffic from the Gateway: Securely send traffic outside the cluster by defining the external service through the Gloo Platform.
👉 Implement Network Policies: Prevent malicious users from bypassing the Egress Gateway by configuring CNI-level Network policies to enforce traffic routing through the Gateway.
👉 Leverage Cilium CNI for Network Policy Enforcement: See how Cilium CNI is utilized to enforce network policies and ensure full control over Egress traffic.
👉 Simplify Istio Resource Configuration: With the Gloo Platform's help, creating the necessary Istio resources (service entries, gateways, destination rules, virtual services, etc.) becomes a breeze.
👉 Apply Layer 7 Policies: Enhance security by defining access policies and deciding who can communicate with specific external services.
👉 Understand Enforcement Layers: Learn how the Gloo Platform translates access policies into Istio authorization policies or network policies based on your requirements.
👉 Test Egress Traffic: Watch us test the setup by accessing an external service through the Egress Gateway and observing the logs.
By the end of this video, you'll have a clear understanding of how the Gloo Platform streamlines the configuration of Egress Gateways and enables seamless integration with Cilium CNI for robust network policies. Don't miss this opportunity to enhance your knowledge and implement efficient Egress traffic security in your Kubernetes clusters.
If you found this video helpful, be sure to like and subscribe for more informative content on Kubernetes, Istio, and other cloud native technologies. Hit the notification bell to stay updated on our latest uploads. Thank you for watching, and we'll see you in the next video!
We'll show you step-by-step how to:
👉 Automate Egress Gateway Deployment: Just like setting up Ingress Gateways, we'll use the Gateway lifecycle manager to automate the deployment of the Egress Gateway quickly.
👉 Originate TLS Traffic from the Gateway: Securely send traffic outside the cluster by defining the external service through the Gloo Platform.
👉 Implement Network Policies: Prevent malicious users from bypassing the Egress Gateway by configuring CNI-level Network policies to enforce traffic routing through the Gateway.
👉 Leverage Cilium CNI for Network Policy Enforcement: See how Cilium CNI is utilized to enforce network policies and ensure full control over Egress traffic.
👉 Simplify Istio Resource Configuration: With the Gloo Platform's help, creating the necessary Istio resources (service entries, gateways, destination rules, virtual services, etc.) becomes a breeze.
👉 Apply Layer 7 Policies: Enhance security by defining access policies and deciding who can communicate with specific external services.
👉 Understand Enforcement Layers: Learn how the Gloo Platform translates access policies into Istio authorization policies or network policies based on your requirements.
👉 Test Egress Traffic: Watch us test the setup by accessing an external service through the Egress Gateway and observing the logs.
By the end of this video, you'll have a clear understanding of how the Gloo Platform streamlines the configuration of Egress Gateways and enables seamless integration with Cilium CNI for robust network policies. Don't miss this opportunity to enhance your knowledge and implement efficient Egress traffic security in your Kubernetes clusters.
If you found this video helpful, be sure to like and subscribe for more informative content on Kubernetes, Istio, and other cloud native technologies. Hit the notification bell to stay updated on our latest uploads. Thank you for watching, and we'll see you in the next video!
- 1 participant
- 7 minutes
7 Jul 2023
Welcome to an exciting demonstration of the seamless integration between Gloo Platform and AWS Lambdas. With Gloo Platform's native integration, AWS Lambdas can be effortlessly integrated into your application architecture. What's even better is that the Gloo Platform Lambda integration is payload compatible with AWS API Gateway and AWS Application Load Balancers, making the transition to Gloo Platform a zero-charge experience.
In this demo, we will showcase how Gloo Platform treats AWS Lambdas as any other workload type, providing a unified control plane for all supported workload types, including Lambdas, Kubernetes services, and virtual machines.
First, we'll introduce a Lambda function that has already been deployed to AWS. This Lambda returns the native AWS API Gateway payload format, ensuring seamless compatibility with Gloo Platform. Additionally, the Lambda includes a log statement, which we'll be able to view in the AWS console later to confirm that the Lambda was successfully invoked in AWS.
Before invoking the Lambda, let's take a closer look at a Gloo Platform resource that is configured to route to the Lambda. This resource specifies a route under the prefix "/Lambda" and points to the already deployed Lambda function in AWS.
Now, let's make a curl request to the Gloo Platform installation hosting the Lambda route. As you can see, the request returns the payload that we previously viewed in the Lambda source code, confirming the successful integration.
To further validate the Lambda invocation, we'll quickly navigate to the AWS CloudWatch console. Here, we can observe the log entry that was generated by the Lambda during its execution. You'll notice that the log statement we saw earlier in the source code is displayed here, providing concrete evidence that the Lambda was indeed invoked in AWS.
Stay tuned for more integrations and powerful capabilities from Gloo Platform. Thank you for joining us in this demo!
In this demo, we will showcase how Gloo Platform treats AWS Lambdas as any other workload type, providing a unified control plane for all supported workload types, including Lambdas, Kubernetes services, and virtual machines.
First, we'll introduce a Lambda function that has already been deployed to AWS. This Lambda returns the native AWS API Gateway payload format, ensuring seamless compatibility with Gloo Platform. Additionally, the Lambda includes a log statement, which we'll be able to view in the AWS console later to confirm that the Lambda was successfully invoked in AWS.
Before invoking the Lambda, let's take a closer look at a Gloo Platform resource that is configured to route to the Lambda. This resource specifies a route under the prefix "/Lambda" and points to the already deployed Lambda function in AWS.
Now, let's make a curl request to the Gloo Platform installation hosting the Lambda route. As you can see, the request returns the payload that we previously viewed in the Lambda source code, confirming the successful integration.
To further validate the Lambda invocation, we'll quickly navigate to the AWS CloudWatch console. Here, we can observe the log entry that was generated by the Lambda during its execution. You'll notice that the log statement we saw earlier in the source code is displayed here, providing concrete evidence that the Lambda was indeed invoked in AWS.
Stay tuned for more integrations and powerful capabilities from Gloo Platform. Thank you for joining us in this demo!
- 1 participant
- 2 minutes
7 Jul 2023
Discover the advanced support for additional API types in Gloo Platform, with a special focus on GraphQL. Unlike traditional pass-through proxies, Gloo Platform offers a unique approach by providing a fully integrated GraphQL server built in C++ and seamlessly integrated with Envoy Proxy.
Experience the power of Gloo Platform's GraphQL capabilities as we explore its features. We start with an existing REST API, a Blog service, and showcase the transformation of this API into a GraphQL API using declarative configuration. No coding is required as Gloo Platform handles the mapping and transformation automatically.
During the demonstration, we dive into the configuration, including the schema definition language (SDL) that defines the GraphQL schema. The power of Gloo Platform becomes evident when we examine the resolvers, which automatically map the existing REST API to the GraphQL schema. This transformation is encapsulated in a route table, a familiar concept within Gloo Platform.
With the configuration in place, we witness the appearance of the GraphQL API in the Gloo Platform UI. The API registry provides a comprehensive view of the schema, including queries and entities. For seamless exploration and interactive query building, we utilize GraphiQL, an intuitive tool that enables us to access and retrieve data from the GraphQL API.
But Gloo Platform doesn't stop at transforming a single API type. It offers the ability to aggregate multiple API types, such as REST and gRPC, into a unified GraphQL API. By adding an additional upstream REST API and annotating it with a resolver, we demonstrate the combination of data sources within the GraphQL server.
This demonstration merely scratches the surface of the powerful capabilities Gloo Platform offers for GraphQL. Explore the endless possibilities and unlock the potential of GraphQL in your API ecosystem with Gloo Platform.
Stay tuned for more content and innovative solutions from Gloo Platform.
Experience the power of Gloo Platform's GraphQL capabilities as we explore its features. We start with an existing REST API, a Blog service, and showcase the transformation of this API into a GraphQL API using declarative configuration. No coding is required as Gloo Platform handles the mapping and transformation automatically.
During the demonstration, we dive into the configuration, including the schema definition language (SDL) that defines the GraphQL schema. The power of Gloo Platform becomes evident when we examine the resolvers, which automatically map the existing REST API to the GraphQL schema. This transformation is encapsulated in a route table, a familiar concept within Gloo Platform.
With the configuration in place, we witness the appearance of the GraphQL API in the Gloo Platform UI. The API registry provides a comprehensive view of the schema, including queries and entities. For seamless exploration and interactive query building, we utilize GraphiQL, an intuitive tool that enables us to access and retrieve data from the GraphQL API.
But Gloo Platform doesn't stop at transforming a single API type. It offers the ability to aggregate multiple API types, such as REST and gRPC, into a unified GraphQL API. By adding an additional upstream REST API and annotating it with a resolver, we demonstrate the combination of data sources within the GraphQL server.
This demonstration merely scratches the surface of the powerful capabilities Gloo Platform offers for GraphQL. Explore the endless possibilities and unlock the potential of GraphQL in your API ecosystem with Gloo Platform.
Stay tuned for more content and innovative solutions from Gloo Platform.
- 1 participant
- 5 minutes
7 Jul 2023
Discover how Gloo Platform can implement a service mesh zero trust architecture in this demonstration. We explore three components: a server API representing a protected service, a client API with legitimate access needs, and a bad actor exploiting traditional controls.
Initially, we observe the service mesh without access controls in place. Active network traffic flows without encryption, authentication, or authorization. Both the client API and the bad actor access sensitive data owned by the server API without restrictions.
Next, we apply a Gloo Platform access policy to secure the API. The policy enforces strict mutual TLS (mTLS) for access and specifies the allowed principles, in this case, the ZTA client API.
After applying the policy, we re-examine the traffic. The line between the client API and the server API is still green, indicating successful communication. However, it now features an mTLS lock icon, signifying encryption, strong identity for authentication and authorization. The bad actor encounters a red line, representing intercepted and denied requests by Gloo Platform.
To summarize, we transform an initially unsecured API into a secure one through Gloo Platform's access policy. The bad actor is denied access, while the legitimate client API communicates with the server API securely, employing encryption, authentication, and authorization using a robust mTLS identity.
Experience the power of Gloo Platform in implementing a service mesh zero trust architecture. Stay tuned for more informative content.
Initially, we observe the service mesh without access controls in place. Active network traffic flows without encryption, authentication, or authorization. Both the client API and the bad actor access sensitive data owned by the server API without restrictions.
Next, we apply a Gloo Platform access policy to secure the API. The policy enforces strict mutual TLS (mTLS) for access and specifies the allowed principles, in this case, the ZTA client API.
After applying the policy, we re-examine the traffic. The line between the client API and the server API is still green, indicating successful communication. However, it now features an mTLS lock icon, signifying encryption, strong identity for authentication and authorization. The bad actor encounters a red line, representing intercepted and denied requests by Gloo Platform.
To summarize, we transform an initially unsecured API into a secure one through Gloo Platform's access policy. The bad actor is denied access, while the legitimate client API communicates with the server API securely, employing encryption, authentication, and authorization using a robust mTLS identity.
Experience the power of Gloo Platform in implementing a service mesh zero trust architecture. Stay tuned for more informative content.
- 1 participant
- 4 minutes
7 Jul 2023
Welcome to an exciting demonstration of Gloo Platform Portal's ability to support multiple logical portals, catering to different tenants. In this video, we'll walk you through the process of managing and targeting APIs within these portals.
As you can see, we have two portals deployed in Gloo Platform Portal. The first portal includes two APIs: the Catstronauts API and the Petstore API. On the other hand, the second portal currently doesn't have any APIs deployed. The APIs associated with each portal are selected based on their labels. In this case, we have a "partner dev portal" label and a "dev portal" label.
To showcase the flexibility of Gloo Platform Portal, let's move the Petstore API from one portal to the other. We can achieve this by simply changing the label of the corresponding API product. Once we make the label change, we add it to the Git repository, commit the changes, and push them. Leveraging the power of Argo CD CI/CD pipeline, we apply this update to our Petstore API product.
Upon synchronization with the cluster, we can observe that the Petstore API product has been removed from one portal. Upon refreshing the page, we witness the Petstore API being seamlessly picked up by the other portal, now catering to different tenants and effectively targeting a new audience.
Prepare to be amazed by the versatility and adaptability of Gloo Platform Portal, as it effortlessly handles multiple logical portals, delivering tailored experiences to different tenants. Stay tuned for more powerful demonstrations and transformative features.
As you can see, we have two portals deployed in Gloo Platform Portal. The first portal includes two APIs: the Catstronauts API and the Petstore API. On the other hand, the second portal currently doesn't have any APIs deployed. The APIs associated with each portal are selected based on their labels. In this case, we have a "partner dev portal" label and a "dev portal" label.
To showcase the flexibility of Gloo Platform Portal, let's move the Petstore API from one portal to the other. We can achieve this by simply changing the label of the corresponding API product. Once we make the label change, we add it to the Git repository, commit the changes, and push them. Leveraging the power of Argo CD CI/CD pipeline, we apply this update to our Petstore API product.
Upon synchronization with the cluster, we can observe that the Petstore API product has been removed from one portal. Upon refreshing the page, we witness the Petstore API being seamlessly picked up by the other portal, now catering to different tenants and effectively targeting a new audience.
Prepare to be amazed by the versatility and adaptability of Gloo Platform Portal, as it effortlessly handles multiple logical portals, delivering tailored experiences to different tenants. Stay tuned for more powerful demonstrations and transformative features.
- 1 participant
- 2 minutes
7 Jul 2023
Get ready to witness the true power of Gloo Platform's multi-cluster, multi-cloud capabilities. In this example, we'll demonstrate how Gloo Platform seamlessly operates in a diverse environment consisting of an AWS management cluster, a Gloo workload cluster in AWS, and another workload cluster in GCP. By leveraging this setup, we'll deploy a Gloo Platform Portal in AWS, along with API products in both AWS and GCP, showcasing how Gloo Platform can unify these different API products from different clusters into a single, cohesive development portal.
As we dive into the demonstration, let's explore the Gloo Platform Dashboard, where we can witness the presence of two clusters within our environment. Cluster one represents an AWS Elastic Kubernetes Service (EKS) cluster, while cluster two corresponds to a Google Kubernetes Engine (GKE) cluster running in Google Cloud. Additionally, we've deployed a developer portal in cluster one, our AWS environment.
When we navigate to the Developer Portal UI, the gateway to our portal, we discover the availability of two remarkable API products: the Catstronauts REST API and the Petstore REST API. By exploring the portal, we can examine the open API specifications of both API products, utilizing either the Redoc or Swagger view. This gives us a comprehensive understanding of the capabilities and functionalities provided by each API.
Now, returning to the Gloo Platform Dashboard, we shift our focus to the APIs section. Here, we observe that the Catstronauts REST API is deployed in cluster one, our AWS environment. On the other hand, the Petstore REST API API product is deployed in cluster two, residing within the Google Cloud ecosystem.
What makes this demonstration truly remarkable is that, despite the deployment of our API products across multiple clusters and clouds, Gloo Platform Portal's multi-cluster and multi-cloud design allows us to utilize a single development portal as a unified window for managing all our API products across various environments.
Prepare to be amazed by Gloo Platform's exceptional capabilities in a multi-cluster, multi-cloud environment. Stay tuned for more demonstrations and powerful features.
As we dive into the demonstration, let's explore the Gloo Platform Dashboard, where we can witness the presence of two clusters within our environment. Cluster one represents an AWS Elastic Kubernetes Service (EKS) cluster, while cluster two corresponds to a Google Kubernetes Engine (GKE) cluster running in Google Cloud. Additionally, we've deployed a developer portal in cluster one, our AWS environment.
When we navigate to the Developer Portal UI, the gateway to our portal, we discover the availability of two remarkable API products: the Catstronauts REST API and the Petstore REST API. By exploring the portal, we can examine the open API specifications of both API products, utilizing either the Redoc or Swagger view. This gives us a comprehensive understanding of the capabilities and functionalities provided by each API.
Now, returning to the Gloo Platform Dashboard, we shift our focus to the APIs section. Here, we observe that the Catstronauts REST API is deployed in cluster one, our AWS environment. On the other hand, the Petstore REST API API product is deployed in cluster two, residing within the Google Cloud ecosystem.
What makes this demonstration truly remarkable is that, despite the deployment of our API products across multiple clusters and clouds, Gloo Platform Portal's multi-cluster and multi-cloud design allows us to utilize a single development portal as a unified window for managing all our API products across various environments.
Prepare to be amazed by Gloo Platform's exceptional capabilities in a multi-cluster, multi-cloud environment. Stay tuned for more demonstrations and powerful features.
- 1 participant
- 2 minutes
7 Jul 2023
In this video, we will showcase how our platform empowers you to efficiently manage your APIs and API products in a Kubernetes and cloud native environment.
To begin, we'll explore a Kubernetes deployment and service that deploys a microservice with a specific API. By leveraging our Gloo annotations, we enable the platform to automatically discover the microservice's OpenAPI specification. Initially, the Kubernetes platform does not have any API documentation available. However, once we deploy our servers and deployments, the platform seamlessly discovers the OpenAPI specification. We can view the complete OpenAPI spec in the Kubernetes custom resource.
Now, we can proceed to deploy our API products using route tables in Gloo Platform Portal. A route table defines the API product, including labels, portal metadata, such as the API title, description, terms of service, contacts, licenses, and more. It also specifies the destination service that implements the API. Upon applying the API product route table, we can see the deployed API in our developer portal, which provides a comprehensive interface. Additionally, the Gloo Platform dashboard showcases the API, its OpenAPI specification, and the JSON schema format.
In the developer portal's frontend UI, which is built using React, we can explore the API product, in this case, the Catstronaut API. It is presented in both Redoc and Swagger views, allowing users to choose their preferred documentation style. We can seamlessly switch between views and utilize the "try-it-out" functionality provided by the platform. Upon execution, we receive a 200 response from the API product we deployed.
To enhance security, we decide to change the API visibility to private, requiring users to log in to access it. By defining a portal group that grants access based on specific claims, we can control the visibility of the API. Applying the portal group allows users with the "users" claim and value to access the API labeled as "tracks" (our customer's API).
Next, we focus on securing our API product through API key authentication and authorization. This involves applying an Auth policy to routes with the label "usage plan Dev portal." Our "tracks" API has the "Dev portal" usage plan, enabling us to enforce API key requirements. We also apply a rate limit policy to control the number of requests per second, minute, or hour that can be sent to our API.
When we revisit our Catstronaut API in the Dev portal UI, we notice that access is now restricted. To generate an API key, we enable the usage plans in the Dev portal configuration. We define three usage plans: bronze, silver, and gold, which align with the rate limiting configuration. These plans encompass both rate limiting and API key authentication. In the Dev portal UI, we can see the three usage plans, and we generate a new API key called "my key." After pasting the API key into the Swagger view, we can access the API and receive a 200 response. However, when the rate limit is exceeded, we receive a 429 "too many requests" response.
Furthermore, we demonstrate the cloud native approach of deploying additional API products using Argo CD and a CI/CD pipeline. We synchronize the Helm chart of a pet store API product with our cluster using Argo CD, resulting in the deployment of the parts, deployments, services, and the API product in the Dev portal. While the Petstore API initially includes only the "paths" API, we introduce two more microservices: the user API and the store API. By adding their OpenAPI specifications to our route table API products, we combine the APIs of these microservices into a single Petstore API product.
To manage the Dev portal configuration and usage plans efficiently, we utilize CI/CD pipelines and GitOps approaches. This allows development and platform teams to control and automate the deployment of APIs, API products, and the Dev portal's configuration. We showcase this by adding a new usage plan called "Platinum" to the Dev portal and rate limit server configuration. Through GitOps and synchronization with the Git repository, the changes are instantly applied, providing an initial usage plan for deployed API products on the dashboard.
Thank you for joining us in this demo of Gloo Platform Portal, where managing your APIs and API products in a Kubernetes and cloud native environment becomes streamlined and efficient. Don't forget to like, share, and subscribe to our channel for more content!
To begin, we'll explore a Kubernetes deployment and service that deploys a microservice with a specific API. By leveraging our Gloo annotations, we enable the platform to automatically discover the microservice's OpenAPI specification. Initially, the Kubernetes platform does not have any API documentation available. However, once we deploy our servers and deployments, the platform seamlessly discovers the OpenAPI specification. We can view the complete OpenAPI spec in the Kubernetes custom resource.
Now, we can proceed to deploy our API products using route tables in Gloo Platform Portal. A route table defines the API product, including labels, portal metadata, such as the API title, description, terms of service, contacts, licenses, and more. It also specifies the destination service that implements the API. Upon applying the API product route table, we can see the deployed API in our developer portal, which provides a comprehensive interface. Additionally, the Gloo Platform dashboard showcases the API, its OpenAPI specification, and the JSON schema format.
In the developer portal's frontend UI, which is built using React, we can explore the API product, in this case, the Catstronaut API. It is presented in both Redoc and Swagger views, allowing users to choose their preferred documentation style. We can seamlessly switch between views and utilize the "try-it-out" functionality provided by the platform. Upon execution, we receive a 200 response from the API product we deployed.
To enhance security, we decide to change the API visibility to private, requiring users to log in to access it. By defining a portal group that grants access based on specific claims, we can control the visibility of the API. Applying the portal group allows users with the "users" claim and value to access the API labeled as "tracks" (our customer's API).
Next, we focus on securing our API product through API key authentication and authorization. This involves applying an Auth policy to routes with the label "usage plan Dev portal." Our "tracks" API has the "Dev portal" usage plan, enabling us to enforce API key requirements. We also apply a rate limit policy to control the number of requests per second, minute, or hour that can be sent to our API.
When we revisit our Catstronaut API in the Dev portal UI, we notice that access is now restricted. To generate an API key, we enable the usage plans in the Dev portal configuration. We define three usage plans: bronze, silver, and gold, which align with the rate limiting configuration. These plans encompass both rate limiting and API key authentication. In the Dev portal UI, we can see the three usage plans, and we generate a new API key called "my key." After pasting the API key into the Swagger view, we can access the API and receive a 200 response. However, when the rate limit is exceeded, we receive a 429 "too many requests" response.
Furthermore, we demonstrate the cloud native approach of deploying additional API products using Argo CD and a CI/CD pipeline. We synchronize the Helm chart of a pet store API product with our cluster using Argo CD, resulting in the deployment of the parts, deployments, services, and the API product in the Dev portal. While the Petstore API initially includes only the "paths" API, we introduce two more microservices: the user API and the store API. By adding their OpenAPI specifications to our route table API products, we combine the APIs of these microservices into a single Petstore API product.
To manage the Dev portal configuration and usage plans efficiently, we utilize CI/CD pipelines and GitOps approaches. This allows development and platform teams to control and automate the deployment of APIs, API products, and the Dev portal's configuration. We showcase this by adding a new usage plan called "Platinum" to the Dev portal and rate limit server configuration. Through GitOps and synchronization with the Git repository, the changes are instantly applied, providing an initial usage plan for deployed API products on the dashboard.
Thank you for joining us in this demo of Gloo Platform Portal, where managing your APIs and API products in a Kubernetes and cloud native environment becomes streamlined and efficient. Don't forget to like, share, and subscribe to our channel for more content!
- 1 participant
- 10 minutes
7 Jul 2023
Welcome to a demonstration of the powerful analytics feature in Gloo Platform Portal API. In this video, we'll showcase how this feature provides valuable insights into API usage.
Our platform's analytics workflow begins when a user or system accesses an API using an API key. The API Gateway, which is an Envoy proxy, validates the API key and verifies authorization for API access. During this validation process, we retrieve additional metadata related to the API key, such as the attached usage plan. This information is then stored in the access log of our API Gateway.
To harness the power of analytics, we employ an open telemetry pipeline to fetch data from the access log. This data is processed within our OTEL (OpenTelemetry) pipeline and stored in one of the supported data stores. In this demonstration, we utilize ClickHouse as the data store for the API access log. The stored data includes requests, response validity, API product access, specific API access details, usage plans, API keys, and more.
By leveraging ClickHouse as a data source, we can visualize the API usage information through a Grafana dashboard. This dynamic dashboard allows us to select the desired product and view usage information based on various parameters. We can choose the usage plan, request URL, HTTP method, response status code, and even filter by user ID. This enables us to analyze request latency, track status codes over time, and identify top API consumers for a specific API.
Furthermore, the dashboard allows us to focus on individual API users by selecting their user IDs. We can examine up to 100 user IDs, matching the top API consumers. Additionally, if we wish to explore the usage of a specific user, we can easily apply a filter based on the username or a partial match. This provides comprehensive insights into total API calls made, status codes over time, request latency, and more.
Apart from the overall API product usage and analytics dashboard, Gloo Platform Portal offers out-of-the-box dashboards for each API product. These dedicated dashboards provide focused information for specific API products or allow users access to relevant analytics for their respective products.
It's worth mentioning that our open telemetry pipeline allows data export to any data store supported by OpenTelemetry. This means the data utilized in our API product usage and analytics dashboard can be exported to other environments for further processing. This opens up exciting possibilities for implementing use cases like API usage monetization and advanced analytics.
Prepare to dive into a world of actionable insights as we explore the API usage analytics capabilities of Gloo Platform Portal. Stay tuned for more features and demonstrations!
Our platform's analytics workflow begins when a user or system accesses an API using an API key. The API Gateway, which is an Envoy proxy, validates the API key and verifies authorization for API access. During this validation process, we retrieve additional metadata related to the API key, such as the attached usage plan. This information is then stored in the access log of our API Gateway.
To harness the power of analytics, we employ an open telemetry pipeline to fetch data from the access log. This data is processed within our OTEL (OpenTelemetry) pipeline and stored in one of the supported data stores. In this demonstration, we utilize ClickHouse as the data store for the API access log. The stored data includes requests, response validity, API product access, specific API access details, usage plans, API keys, and more.
By leveraging ClickHouse as a data source, we can visualize the API usage information through a Grafana dashboard. This dynamic dashboard allows us to select the desired product and view usage information based on various parameters. We can choose the usage plan, request URL, HTTP method, response status code, and even filter by user ID. This enables us to analyze request latency, track status codes over time, and identify top API consumers for a specific API.
Furthermore, the dashboard allows us to focus on individual API users by selecting their user IDs. We can examine up to 100 user IDs, matching the top API consumers. Additionally, if we wish to explore the usage of a specific user, we can easily apply a filter based on the username or a partial match. This provides comprehensive insights into total API calls made, status codes over time, request latency, and more.
Apart from the overall API product usage and analytics dashboard, Gloo Platform Portal offers out-of-the-box dashboards for each API product. These dedicated dashboards provide focused information for specific API products or allow users access to relevant analytics for their respective products.
It's worth mentioning that our open telemetry pipeline allows data export to any data store supported by OpenTelemetry. This means the data utilized in our API product usage and analytics dashboard can be exported to other environments for further processing. This opens up exciting possibilities for implementing use cases like API usage monetization and advanced analytics.
Prepare to dive into a world of actionable insights as we explore the API usage analytics capabilities of Gloo Platform Portal. Stay tuned for more features and demonstrations!
- 1 participant
- 4 minutes
1 May 2023
Gloo Platform integrates API gateway, API management, and Istio service mesh into a unified application networking platform that scales across multiple clusters. In this video, we will explore a common incremental adoption pattern, transitioning from a single cluster to multiple clusters across regions or clouds to achieve high availability and improve performance.
- 1 participant
- 10 minutes
10 Mar 2022
For more great content, visit https://solocon.io
SoloCon 2022:
How Constant Contact is Leveraging Gloo and Istio to Transform our Platform
Speakers:
Dave Ortiz
Senior Principal Software Engineer, Constant Contact
Session Abstract:
Interested in modernizing your microservice architecture? Join senior principal software engineer Dave Ortiz as he walks you through Constant Contact's journey as they designed their microservices, exposed APIs, and integrated new and old services together.
Track:
Service Mesh and Application Networking
SoloCon 2022:
How Constant Contact is Leveraging Gloo and Istio to Transform our Platform
Speakers:
Dave Ortiz
Senior Principal Software Engineer, Constant Contact
Session Abstract:
Interested in modernizing your microservice architecture? Join senior principal software engineer Dave Ortiz as he walks you through Constant Contact's journey as they designed their microservices, exposed APIs, and integrated new and old services together.
Track:
Service Mesh and Application Networking
- 1 participant
- 32 minutes
