// Copyright 2017 Istio Authors
//
//   Licensed under the Apache License, Version 2.0 (the "License");
//   you may not use this file except in compliance with the License.
//   You may obtain a copy of the License at
//
//       http://www.apache.org/licenses/LICENSE-2.0
//
//   Unless required by applicable law or agreed to in writing, software
//   distributed under the License is distributed on an "AS IS" BASIS,
//   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
//   See the License for the specific language governing permissions and
//   limitations under the License.

syntax = "proto3";

import "routing/v1alpha1/route_rule.proto";

package istio.routing.v1alpha1;

option go_package = "istio.io/api/routing/v1alpha1";

// Egress rules describe the properties of a service outside Istio. When transparent proxying
// is used, egress rules signify a white listed set of external services that microserves in the mesh
// are allowed to access. A subset of routing rules and all destination policies can be applied
// on the service targeted by an egress rule. TCP services and HTTP-based services can be expressed
// by an egress rule. The destination of an egress rule for HTTP-based services must be an IP or a domain name,
// optionally with a wildcard prefix  (e.g., *.foo.com). For TCP based services, the destination of an
// egress rule must be an IP or a block of IPs in CIDR notation.
//
// If TLS origination from the sidecar is desired, the protocol
// associated with the service port must be marked as HTTPS, and the service is expected to
// be accessed over HTTP (e.g., http://gmail.com:443). The sidecar will automatically upgrade
// the connection to TLS when initiating a connection with the external service.
//
// For example, the following egress rule describes the set of services hosted under the *.foo.com domain
//
//     kind: EgressRule
//     metadata:
//       name: foo-egress-rule
//     spec:
//       destination:
//         service: *.foo.com
//       ports:
//         - port: 80
//           protocol: http
//         - port: 443
//           protocol: https
//
// The following egress rule describes the set of services accessed by a block of IPs
//
//     kind: EgressRule
//     metadata:
//       name: bar-egress-rule
//     spec:
//       destination:
//         service: 92.198.174.192/27
//       ports:
//         - port: 111
//           protocol: tcp
//
message EgressRule {
  // Port describes the properties of a specific TCP port of an external service.
  message Port {
    // A valid non-negative integer port number.
    int32 port = 1;
    // The protocol to communicate with the external services.
    // MUST BE one of HTTP|HTTPS|GRPC|HTTP2|TCP|MONGO.
    string protocol = 2;
  }

  // REQUIRED: A domain name, optionally with a wildcard prefix, or an IP, or a block of IPs
  // associated with the external service.
  // ONLY the "service" field of "destination" will be taken into consideration. Name,
  // namespace, domain and labels are ignored. Routing rules and destination policies that
  // refer to these external services must have identical specification for the destination
  // as the corresponding egress rule.
  //
  // The "service" field of "destination" for HTTP-based services must be an IP or a domain name,
  // optionally with a wildcard prefix. Wildcard domain specifications must conform to format
  // allowed by Envoy's Virtual Host specification, such as “*.foo.com” or “*-bar.foo.com”.
  // The character '*' in a domain specification indicates a non-empty string. Hence, a wildcard
  // domain of form “*-bar.foo.com” will match “baz-bar.foo.com” but not “-bar.foo.com”.
  //
  // The "service" field of "destination" for TCP services must be an IP or a block of IPs in CIDR notation.
  IstioService destination = 1;

  // REQUIRED: list of ports on which the external service is available.
  repeated Port ports = 2;

  // Forward all the external traffic through a dedicated egress proxy. It is used in some scenarios
  // where there is a requirement that all the external traffic goes through special dedicated nodes/pods.
  // These dedicated egress nodes could then be more closely monitored for security vulnerabilities.
  //
  // The default is false, i.e. the sidecar forwards external traffic directly to the external service.
  bool use_egress_proxy = 3;
}
