- Why Ambassador?
- Features and Benefits
- Using Ambassador in Your Organization
- Ambassador vs. Other Software
- Connecting Services
- Service Mesh
- Best Practices
- IDP Support
- Developer PortalPortal
- Upgrading Ambassador
- Statistics and Monitoring
- Need Help?
This feature is supported in Ambassador Pro. Ambassador Pro helps developers and operators accelerate their adoption of Kubernetes.
Register here to get started with a free trial of Ambassador Pro.
FilterPolicy custom resource definition (CRD) gives you fine-grained control over filters. Since authentication and access control is implemented in specific filters, the
FilterPolicy CRD can be used for access control as well.
rule for the
FilterPolicy CRD is a set of hosts, paths, and filters that indicate which filters should be applied to a given path or host.
||the Host that a given rule should match|
||the URL path that a given rule should match to|
||the name of a given filter to be applied|
* is supported for both
The following policy shows how the
keycloak is applied to requests to
/httpbin/headers, while requests to
/httpbin/ip are public.
apiVersion: getambassador.io/v1beta2 kind: FilterPolicy metadata: name: httpbin-policy namespace: default spec: rules: - host: "*" path: /httpbin/ip filters: null # make this path public - host: "*" path: /httpbin/headers filters: - name: keycloak
In this example, the
foo-keycloak filter is used for requests to
foo.bar.com, while the
example-auth0 filter is used for requests to
example.com. This configuration is useful if you are hosting multiple domains in the same cluster.
apiVersion: getambassador.io/v1beta1 kind: Policy metadata: name: multi-domain-policy spec: rules: - host: foo.bar.com path: * filters: - name: foo-keycloak - host: example.com path: * filters: - name: example-auth0