Documentation
¶
Overview ¶
Code generated by protoc-gen-alias. DO NOT EDIT.
Code generated by protoc-gen-alias. DO NOT EDIT.
Code generated by protoc-gen-alias. DO NOT EDIT.
Index ¶
- type AuthorizationPolicy
- type AuthorizationPolicy_Action
- type AuthorizationPolicy_ExtensionProvider
- type AuthorizationPolicy_Provider
- type ClaimToHeader
- type Condition
- type JWTHeader
- type JWTRule
- type Operation
- type PeerAuthentication
- type PeerAuthentication_MutualTLS
- type PeerAuthentication_MutualTLS_Mode
- type RequestAuthentication
- type Rule
- type Rule_From
- type Rule_To
- type Source
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
type AuthorizationPolicy ¶
type AuthorizationPolicy = v1beta1.AuthorizationPolicy
AuthorizationPolicy enables access control on workloads.
<!-- crd generation tags +cue-gen:AuthorizationPolicy:groupName:security.istio.io +cue-gen:AuthorizationPolicy:versions:v1beta1,v1 +cue-gen:AuthorizationPolicy:storageVersion +cue-gen:AuthorizationPolicy:annotations:helm.sh/resource-policy=keep +cue-gen:AuthorizationPolicy:labels:app=istio-pilot,chart=istio,istio=security,heritage=Tiller,release=istio +cue-gen:AuthorizationPolicy:subresource:status +cue-gen:AuthorizationPolicy:scope:Namespaced +cue-gen:AuthorizationPolicy:resource:categories=istio-io,security-istio-io,shortNames=ap,plural=authorizationpolicies +cue-gen:AuthorizationPolicy:preserveUnknownFields:false +cue-gen:AuthorizationPolicy:printerColumn:name=Action,type=string,JSONPath=.spec.action,description="The operation to take." +cue-gen:AuthorizationPolicy:printerColumn:name=Age,type=date,JSONPath=.metadata.creationTimestamp,description="CreationTimestamp is a timestamp representing the server time when this object was created. It is not guaranteed to be set in happens-before order across separate operations. Clients may not set this value. It is represented in RFC3339 form and is in UTC. Populated by the system. Read-only. Null for lists. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#metadata" -->
<!-- go code generation tags +kubetype-gen +kubetype-gen:groupVersion=security.istio.io/v1beta1 +genclient +k8s:deepcopy-gen=true --> +kubebuilder:validation:XValidation:message="only one of targetRefs or selector can be set",rule="(has(self.selector)?1:0)+(has(self.targetRef)?1:0)+(has(self.targetRefs)?1:0)<=1"
type AuthorizationPolicy_Action ¶
type AuthorizationPolicy_Action = v1beta1.AuthorizationPolicy_Action
Action specifies the operation to take.
const AuthorizationPolicy_ALLOW AuthorizationPolicy_Action = v1beta1.AuthorizationPolicy_ALLOW
Allow a request only if it matches the rules. This is the default type.
const AuthorizationPolicy_AUDIT AuthorizationPolicy_Action = v1beta1.AuthorizationPolicy_AUDIT
Audit a request if it matches any of the rules.
const AuthorizationPolicy_CUSTOM AuthorizationPolicy_Action = v1beta1.AuthorizationPolicy_CUSTOM
The CUSTOM action allows an extension to handle the user request if the matching rules evaluate to true. The extension is evaluated independently and before the native ALLOW and DENY actions. When used together, A request is allowed if and only if all the actions return allow, in other words, the extension cannot bypass the authorization decision made by ALLOW and DENY action. Extension behavior is defined by the named providers declared in MeshConfig. The authorization policy refers to the extension by specifying the name of the provider. One example use case of the extension is to integrate with a custom external authorization system to delegate the authorization decision to it.
The following authorization policy applies to an ingress gateway and delegates the authorization check to a named extension `my-custom-authz` if the request path has prefix `/admin/`.
```yaml apiVersion: security.istio.io/v1 kind: AuthorizationPolicy metadata:
name: ext-authz namespace: istio-system
spec:
selector:
matchLabels:
app: istio-ingressgateway
action: CUSTOM
provider:
name: "my-custom-authz"
rules:
- to:
- operation:
paths: ["/admin/*"]
```
const AuthorizationPolicy_DENY AuthorizationPolicy_Action = v1beta1.AuthorizationPolicy_DENY
Deny a request if it matches any of the rules.
type AuthorizationPolicy_ExtensionProvider ¶
type AuthorizationPolicy_ExtensionProvider = v1beta1.AuthorizationPolicy_ExtensionProvider
type AuthorizationPolicy_Provider ¶
type AuthorizationPolicy_Provider = v1beta1.AuthorizationPolicy_Provider
Specifies detailed configuration of the CUSTOM action. Must be used only with CUSTOM action.
type ClaimToHeader ¶
type ClaimToHeader = v1beta1.ClaimToHeader
This message specifies the detail for copying claim to header.
type JWTRule ¶
JSON Web Token (JWT) token format for authentication as defined by [RFC 7519](https://tools.ietf.org/html/rfc7519). See [OAuth 2.0](https://tools.ietf.org/html/rfc6749) and [OIDC 1.0](http://openid.net/connect) for how this is used in the whole authentication flow.
Examples:
Spec for a JWT that is issued by `https://example.com`, with the audience claims must be either `bookstore_android.apps.example.com` or `bookstore_web.apps.example.com`. The token should be presented at the `Authorization` header (default). The JSON Web Key Set (JWKS) will be discovered following OpenID Connect protocol.
```yaml issuer: https://example.com audiences:
- bookstore_android.apps.example.com bookstore_web.apps.example.com
```
This example specifies a token in a non-default location (`x-goog-iap-jwt-assertion` header). It also defines the URI to fetch JWKS explicitly.
```yaml issuer: https://example.com jwksUri: https://example.com/.secret/jwks.json fromHeaders: - "x-goog-iap-jwt-assertion" ``` +kubebuilder:validation:XValidation:message="only one of jwks or jwksUri can be set",rule="(has(self.jwksUri)?1:0)+(has(self.jwks_uri)?1:0)+(has(self.jwks)?1:0)<=1"
type Operation ¶
Operation specifies the operations of a request. Fields in the operation are ANDed together.
For example, the following operation matches if the host has suffix `.example.com` and the method is `GET` or `HEAD` and the path doesn't have prefix `/admin`.
```yaml hosts: ["*.example.com"] methods: ["GET", "HEAD"] notPaths: ["/admin*"] ```
type PeerAuthentication ¶ added in v1.22.0
type PeerAuthentication = v1beta1.PeerAuthentication
PeerAuthentication defines mutual TLS (mTLS) requirements for incoming connections.
In sidecar mode, PeerAuthentication determines whether or not mTLS is allowed or required for connections to an Envoy proxy sidecar.
In ambient mode, security is transparently enabled for a pod by the ztunnel node agent. (Traffic between proxies uses the HBONE protocol, which includes encryption with mTLS.) Because of this, `DISABLE` mode is not supported. `STRICT` mode is useful to ensure that connections that bypass the mesh are not possible.
Examples:
Policy to require mTLS traffic for all workloads under namespace `foo`: ```yaml apiVersion: security.istio.io/v1 kind: PeerAuthentication metadata:
name: default namespace: foo
spec:
mtls: mode: STRICT
``` For mesh level, put the policy in root-namespace according to your Istio installation.
Policies to allow both mTLS and plaintext traffic for all workloads under namespace `foo`, but require mTLS for workload `finance`. ```yaml apiVersion: security.istio.io/v1 kind: PeerAuthentication metadata:
name: default namespace: foo
spec:
mtls: mode: PERMISSIVE
--- apiVersion: security.istio.io/v1 kind: PeerAuthentication metadata:
name: finance namespace: foo
spec:
selector:
matchLabels:
app: finance
mtls:
mode: STRICT
``` Policy that enables strict mTLS for all `finance` workloads, but leaves the port `8080` to plaintext. Note the port value in the `portLevelMtls` field refers to the port of the workload, not the port of the Kubernetes service. ```yaml apiVersion: security.istio.io/v1 kind: PeerAuthentication metadata:
name: default namespace: foo
spec:
selector:
matchLabels:
app: finance
mtls:
mode: STRICT
portLevelMtls:
8080:
mode: DISABLE
``` Policy that inherits mTLS mode from namespace (or mesh) settings, and disables mTLS for workload port `8080`. ```yaml apiVersion: security.istio.io/v1 kind: PeerAuthentication metadata:
name: default namespace: foo
spec:
selector:
matchLabels:
app: finance
mtls:
mode: UNSET
portLevelMtls:
8080:
mode: DISABLE
```
<!-- crd generation tags +cue-gen:PeerAuthentication:groupName:security.istio.io +cue-gen:PeerAuthentication:versions:v1beta1,v1 +cue-gen:PeerAuthentication:storageVersion +cue-gen:PeerAuthentication:annotations:helm.sh/resource-policy=keep +cue-gen:PeerAuthentication:labels:app=istio-pilot,chart=istio,istio=security,heritage=Tiller,release=istio +cue-gen:PeerAuthentication:subresource:status +cue-gen:PeerAuthentication:scope:Namespaced +cue-gen:PeerAuthentication:resource:categories=istio-io,security-istio-io,shortNames=pa +cue-gen:PeerAuthentication:preserveUnknownFields:false +cue-gen:PeerAuthentication:printerColumn:name=Mode,type=string,JSONPath=.spec.mtls.mode,description="Defines the mTLS mode used for peer authentication." +cue-gen:PeerAuthentication:printerColumn:name=Age,type=date,JSONPath=.metadata.creationTimestamp,description="CreationTimestamp is a timestamp representing the server time when this object was created. It is not guaranteed to be set in happens-before order across separate operations. Clients may not set this value. It is represented in RFC3339 form and is in UTC. Populated by the system. Read-only. Null for lists. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#metadata" -->
<!-- go code generation tags +kubetype-gen +kubetype-gen:groupVersion=security.istio.io/v1beta1 +genclient +k8s:deepcopy-gen=true --> +kubebuilder:validation:XValidation:message="portLevelMtls requires selector",rule="(has(self.selector) && has(self.selector.matchLabels) && self.selector.matchLabels.size() > 0) || !has(self.portLevelMtls)"
type PeerAuthentication_MutualTLS ¶ added in v1.22.0
type PeerAuthentication_MutualTLS = v1beta1.PeerAuthentication_MutualTLS
Mutual TLS settings.
type PeerAuthentication_MutualTLS_Mode ¶ added in v1.22.0
type PeerAuthentication_MutualTLS_Mode = v1beta1.PeerAuthentication_MutualTLS_Mode
const PeerAuthentication_MutualTLS_DISABLE PeerAuthentication_MutualTLS_Mode = v1beta1.PeerAuthentication_MutualTLS_DISABLE
Connection is not tunneled.
const PeerAuthentication_MutualTLS_PERMISSIVE PeerAuthentication_MutualTLS_Mode = v1beta1.PeerAuthentication_MutualTLS_PERMISSIVE
Connection can be either plaintext or mTLS tunnel.
const PeerAuthentication_MutualTLS_STRICT PeerAuthentication_MutualTLS_Mode = v1beta1.PeerAuthentication_MutualTLS_STRICT
Connection is an mTLS tunnel (TLS with client cert must be presented).
const PeerAuthentication_MutualTLS_UNSET PeerAuthentication_MutualTLS_Mode = v1beta1.PeerAuthentication_MutualTLS_UNSET
Inherit from parent, if has one. Otherwise treated as `PERMISSIVE`.
type RequestAuthentication ¶
type RequestAuthentication = v1beta1.RequestAuthentication
RequestAuthentication defines what request authentication methods are supported by a workload. It will reject a request if the request contains invalid authentication information, based on the configured authentication rules. A request that does not contain any authentication credentials will be accepted but will not have any authenticated identity. To restrict access to authenticated requests only, this should be accompanied by an authorization rule. Examples:
- Require JWT for all request for workloads that have label `app:httpbin`
```yaml apiVersion: security.istio.io/v1 kind: RequestAuthentication metadata:
name: httpbin namespace: foo
spec:
selector:
matchLabels:
app: httpbin
jwtRules:
- issuer: "issuer-foo"
jwksUri: https://example.com/.well-known/jwks.json
--- apiVersion: security.istio.io/v1 kind: AuthorizationPolicy metadata:
name: httpbin namespace: foo
spec:
selector:
matchLabels:
app: httpbin
rules:
- from:
- source:
requestPrincipals: ["*"]
```
- A policy in the root namespace ("istio-system" by default) applies to workloads in all namespaces in a mesh. The following policy makes all workloads only accept requests that contain a valid JWT token.
```yaml apiVersion: security.istio.io/v1 kind: RequestAuthentication metadata:
name: req-authn-for-all namespace: istio-system
spec:
jwtRules: - issuer: "issuer-foo" jwksUri: https://example.com/.well-known/jwks.json
--- apiVersion: security.istio.io/v1 kind: AuthorizationPolicy metadata:
name: require-jwt-for-all namespace: istio-system
spec:
rules:
- from:
- source:
requestPrincipals: ["*"]
```
- The next example shows how to set a different JWT requirement for a different `host`. The `RequestAuthentication` declares it can accept JWTs issued by either `issuer-foo` or `issuer-bar` (the public key set is implicitly set from the OpenID Connect spec).
```yaml apiVersion: security.istio.io/v1 kind: RequestAuthentication metadata:
name: httpbin namespace: foo
spec:
selector:
matchLabels:
app: httpbin
jwtRules:
- issuer: "issuer-foo"
- issuer: "issuer-bar"
--- apiVersion: security.istio.io/v1 kind: AuthorizationPolicy metadata:
name: httpbin namespace: foo
spec:
selector:
matchLabels:
app: httpbin
rules:
- from:
- source:
requestPrincipals: ["issuer-foo/*"]
to:
- operation:
hosts: ["example.com"]
- from:
- source:
requestPrincipals: ["issuer-bar/*"]
to:
- operation:
hosts: ["another-host.com"]
```
- You can fine tune the authorization policy to set different requirement per path. For example, to require JWT on all paths, except /healthz, the same `RequestAuthentication` can be used, but the authorization policy could be:
```yaml apiVersion: security.istio.io/v1 kind: AuthorizationPolicy metadata:
name: httpbin namespace: foo
spec:
selector:
matchLabels:
app: httpbin
rules:
- from:
- source:
requestPrincipals: ["*"]
- to:
- operation:
paths: ["/healthz"]
```
[Experimental] Routing based on derived [metadata](https://istio.io/latest/docs/reference/config/security/conditions/) is now supported. A prefix '@' is used to denote a match against internal metadata instead of the headers in the request. Currently this feature is only supported for the following metadata:
- `request.auth.claims.{claim-name}[.{nested-claim}]*` which are extracted from validated JWT tokens. Use the `.` or `[]` as a separator for nested claim names. Examples: `request.auth.claims.sub`, `request.auth.claims.name.givenName` and `request.auth.claims[foo.com/name]`. For more information, see [JWT claim based routing](https://istio.io/latest/docs/tasks/security/authentication/jwt-route/).
The use of matches against JWT claim metadata is only supported in Gateways. The following example shows:
- RequestAuthentication to decode and validate a JWT. This also makes the `@request.auth.claims` available for use in the VirtualService. - AuthorizationPolicy to check for valid principals in the request. This makes the JWT required for the request. - VirtualService to route the request based on the "sub" claim.
```yaml apiVersion: security.istio.io/v1 kind: RequestAuthentication metadata:
name: jwt-on-ingress namespace: istio-system
spec:
selector:
matchLabels:
app: istio-ingressgateway
jwtRules:
- issuer: "example.com"
jwksUri: https://example.com/.well-known/jwks.json
--- apiVersion: security.istio.io/v1 kind: AuthorizationPolicy metadata:
name: require-jwt namespace: istio-system
spec:
selector:
matchLabels:
app: istio-ingressgateway
rules:
- from:
- source:
requestPrincipals: ["*"]
--- apiVersion: networking.istio.io/v1 kind: VirtualService metadata:
name: route-jwt
spec:
hosts:
- foo.prod.svc.cluster.local
gateways:
- istio-ingressgateway
http:
- name: "v2"
match:
- headers:
"@request.auth.claims.sub":
exact: "dev"
route:
- destination:
host: foo.prod.svc.cluster.local
subset: v2
- name: "default"
route:
- destination:
host: foo.prod.svc.cluster.local
subset: v1
```
<!-- crd generation tags +cue-gen:RequestAuthentication:groupName:security.istio.io +cue-gen:RequestAuthentication:versions:v1beta1,v1 +cue-gen:RequestAuthentication:storageVersion +cue-gen:RequestAuthentication:annotations:helm.sh/resource-policy=keep +cue-gen:RequestAuthentication:labels:app=istio-pilot,chart=istio,istio=security,heritage=Tiller,release=istio +cue-gen:RequestAuthentication:subresource:status +cue-gen:RequestAuthentication:scope:Namespaced +cue-gen:RequestAuthentication:resource:categories=istio-io,security-istio-io,shortNames=ra +cue-gen:RequestAuthentication:preserveUnknownFields:false -->
<!-- go code generation tags +kubetype-gen +kubetype-gen:groupVersion=security.istio.io/v1beta1 +genclient +k8s:deepcopy-gen=true --> +kubebuilder:validation:XValidation:message="only one of targetRefs or selector can be set",rule="(has(self.selector)?1:0)+(has(self.targetRef)?1:0)+(has(self.targetRefs)?1:0)<=1"
type Rule ¶
Rule matches requests from a list of sources that perform a list of operations subject to a list of conditions. A match occurs when at least one source, one operation and all conditions matches the request. An empty rule is always matched.
Any string field in the rule supports Exact, Prefix, Suffix and Presence match:
- Exact match: `abc` will match on value `abc`. - Prefix match: `abc*` will match on value `abc` and `abcd`. - Suffix match: `*abc` will match on value `abc` and `xabc`. - Presence match: `*` will match when value is not empty.
type Source ¶
Source specifies the source identities of a request. Fields in the source are ANDed together.
For example, the following source matches if the principal is `admin` or `dev` and the namespace is `prod` or `test` and the ip is not `203.0.113.4`.
```yaml principals: ["admin", "dev"] namespaces: ["prod", "test"] notIpBlocks: ["203.0.113.4"] ```
Source Files