optional SubjectAccessReviewStatus status = 3;
}

// SelfSubjectAccessReviewSpec is a description of the access request.  Exactly one of ResourceAuthorizationAttributes
// and NonResourceAuthorizationAttributes must be set
message SelfSubjectAccessReviewSpec {
  // ResourceAuthorizationAttributes describes information for a resource access request
  // +optional
  optional ResourceAttributes resourceAttributes = 1;

  optional SubjectAccessReviewStatus status = 3;
}

// SelfSubjectAccessReviewSpec is a description of the access request.  Exactly one of ResourceAuthorizationAttributes
// and NonResourceAuthorizationAttributes must be set
message SelfSubjectAccessReviewSpec {
  // ResourceAuthorizationAttributes describes information for a resource access request
  // +optional
  optional ResourceAttributes resourceAttributes = 1;

```

4) `gateways` charts install a load balancer with `ingress` and `egress`.

Ingress secrets and access should be separated from the control plane.

```console
helm install -n istio-system istio-ingress manifests/charts/gateways/istio-ingress --set profile=openshift
```

Egress secrets and access should be separated from the control plane.

```console

roles to manage different parts of Istio. For example, a security team would maintain the
root CA and policy, a telemetry team may only have access to Prometheus,
and a different team may maintain the control plane components (which are highly security sensitive).

The install is organized in 'environments' - each environment consists of a set of components

// user in the cluster, because they can be mounted by pods using the
// `clusterTrustBundle` projection.  All service accounts have read access to
// ClusterTrustBundles by default.  Users who only have namespace-level access
// to a cluster can read ClusterTrustBundles by impersonating a serviceaccount
// that they have access to.
//
// It can be optionally associated with a particular assigner, in which case it

to allow arbitrary customizations.

If the change truly is generally purpose, it is generally preferred to have broader APIs. For example, instead of providing
direct access to each of the complex fields in [affinity](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/), just providing
a single `affinity` field that is passed through as-is to the Kubernetes resource.

)

func TestDashboard(t *testing.T) {
	cases := []testutil.TestCase{
		{ // case 0
			Args:           strings.Split("--browser=false", " "),
			ExpectedRegexp: regexp.MustCompile("Access to Istio web UIs"),
		},
		{ // case 1
			Args:           strings.Split("invalid --browser=false", " "),
			ExpectedRegexp: regexp.MustCompile(`unknown dashboard "invalid"`),
			WantException:  true,
		},

			break
		}
	}
	return responses, nil
}

// queryDebugSynczViaAgents sends a debug/syncz xDS request via Istio Agents.
// By this way, even if istioctl cannot access a specific `istiod` instance directly,
// `istioctl` can access the debug endpoint.
// If `all` is true, `queryDebugSynczViaAgents` iterates all the pod having a proxy
// except the pods of which status information is already queried.

      tracing:
      {{- if eq .Values.global.proxy.tracer "lightstep" }}
        lightstep:
          # Address of the LightStep Satellite pool
          address: {{ .Values.global.tracer.lightstep.address }}
          # Access Token used to communicate with the Satellite pool
          accessToken: {{ .Values.global.tracer.lightstep.accessToken }}
      {{- else if eq .Values.global.proxy.tracer "zipkin" }}
        zipkin:

# If we are not using the default, assume its private and we need to authenticate
if [[ "${ISTIO_ZTUNNEL_BASE_URL}" != "https://storage.googleapis.com/istio-build/ztunnel" ]]; then
  AUTH_HEADER="Authorization: Bearer $(gcloud auth print-access-token)"
  export AUTH_HEADER
fi

ZTUNNEL_REPO_SHA="${ZTUNNEL_REPO_SHA:-$(grep ZTUNNEL_REPO_SHA istio.deps  -A 4 | grep lastStableSHA | cut -f 4 -d '"')}"