admin/kubesphere
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

update dependencies

Browse Source 
Signed-off-by: hongming <talonwan@yunify.com>
This commit is contained in:
hongming
2020-12-22 16:48:26 +08:00
parent 4a11a50544
commit fe6c5de00f
2857 changed files with 252134 additions and 115656 deletions
Download Patch File Download Diff File Expand all files Collapse all files

430
vendor/istio.io/api/rbac/v1alpha1/istio.rbac.v1alpha1.pb.html generated vendored
View File

@@ -1,12 +1,11 @@
---
title: RBAC (deprecated)
description: Configuration for Role Based Access Control.
location: https://istio.io/docs/reference/config/security/istio.rbac.v1alpha1.html
title: istio.rbac.v1alpha1
layout: protoc-gen-docs
generator: protoc-gen-docs
weight: 40
aliases: [/docs/reference/config/authorization/istio.rbac.v1alpha1.html]
number_of_entries: 9
schema: istio.rbac.v1alpha1.RbacConfig
schema: istio.rbac.v1alpha1.ServiceRole
schema: istio.rbac.v1alpha1.ServiceRoleBinding
number_of_entries: 0
---
<p>Note: The v1alpha1 RBAC policy is deprecated by the v1beta1 Authorization policy.
This page is kept for migration purpose and will be removed in Istio 1.6.</p>
@@ -19,7 +18,7 @@ the following standard fields:</p>
<ul>
<li>services: a list of services.</li>
<li>methods: A list of HTTP methods. You can set the value to <code>\*</code> to include all HTTP methods.
<li>methods: A list of HTTP methods. You can set the value to <code>[&quot;*&quot;]</code> to include all HTTP methods.
This field should not be set for TCP services. The policy will be ignored.
For gRPC services, only <code>POST</code> is allowed; other methods will result in denying services.</li>
<li>paths: HTTP paths or gRPC methods. Note that gRPC methods should be
@@ -80,420 +79,3 @@ spec:
name: &quot;products-viewer&quot;
</code></pre>
<h2 id="AccessRule">AccessRule</h2>
<section>
<p>AccessRule defines a permission to access a list of services.</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
<th>Required</th>
</tr>
</thead>
<tbody>
<tr id="AccessRule-services">
<td><code>services</code></td>
<td><code>string[]</code></td>
<td>
<p>A list of service names.
Exact match, prefix match, and suffix match are supported for service names.
For example, the service name &ldquo;bookstore.mtv.cluster.local&rdquo; matches
&ldquo;bookstore.mtv.cluster.local&rdquo; (exact match), or &ldquo;bookstore*&rdquo; (prefix match),
or &ldquo;*.mtv.cluster.local&rdquo; (suffix match).
If set to [&rdquo;*&rdquo;], it refers to all services in the namespace.</p>
</td>
<td>
Yes
</td>
</tr>
<tr id="AccessRule-paths">
<td><code>paths</code></td>
<td><code>string[]</code></td>
<td>
<p>Optional. A list of HTTP paths or gRPC methods.
gRPC methods must be presented as fully-qualified name in the form of
&ldquo;/packageName.serviceName/methodName&rdquo; and are case sensitive.
Exact match, prefix match, and suffix match are supported. For example,
the path &ldquo;/books/review&rdquo; matches &ldquo;/books/review&rdquo; (exact match),
or &ldquo;/books/*&rdquo; (prefix match), or &ldquo;*/review&rdquo; (suffix match).
If not specified, it matches to any path.
This field should not be set for TCP services. The policy will be ignored.</p>
</td>
<td>
No
</td>
</tr>
<tr id="AccessRule-methods">
<td><code>methods</code></td>
<td><code>string[]</code></td>
<td>
<p>Optional. A list of HTTP methods (e.g., &ldquo;GET&rdquo;, &ldquo;POST&rdquo;).
If not specified or specified as &ldquo;*&rdquo;, it matches to any methods.
This field should not be set for TCP services. The policy will be ignored.
For gRPC services, only <code>POST</code> is allowed; other methods will result in denying services.</p>
</td>
<td>
No
</td>
</tr>
<tr id="AccessRule-constraints">
<td><code>constraints</code></td>
<td><code><a href="#AccessRule-Constraint">Constraint[]</a></code></td>
<td>
<p>Optional. Extra constraints in the ServiceRole specification.</p>
</td>
<td>
No
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="AccessRule-Constraint">AccessRule.Constraint</h2>
<section>
<p>Definition of a custom constraint. The supported keys are listed in the &ldquo;constraint and properties&rdquo; page.</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
<th>Required</th>
</tr>
</thead>
<tbody>
<tr id="AccessRule-Constraint-key">
<td><code>key</code></td>
<td><code>string</code></td>
<td>
<p>Key of the constraint.</p>
</td>
<td>
No
</td>
</tr>
<tr id="AccessRule-Constraint-values">
<td><code>values</code></td>
<td><code>string[]</code></td>
<td>
<p>List of valid values for the constraint.
Exact match, prefix match, and suffix match are supported.
For example, the value &ldquo;v1alpha2&rdquo; matches &ldquo;v1alpha2&rdquo; (exact match),
or &ldquo;v1*&rdquo; (prefix match), or &ldquo;*alpha2&rdquo; (suffix match).</p>
</td>
<td>
No
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="RbacConfig">RbacConfig</h2>
<section>
<p>RbacConfig implements the ClusterRbacConfig Custom Resource Definition for controlling Istio RBAC behavior.
The ClusterRbacConfig Custom Resource is a singleton where only one ClusterRbacConfig should be created
globally in the mesh and the namespace should be the same to other Istio components, which usually is <code>istio-system</code>.</p>
<p>Below is an example of an <code>ClusterRbacConfig</code> resource called <code>istio-rbac-config</code> which enables Istio RBAC for all
services in the default namespace.</p>
<pre><code class="language-yaml">apiVersion: &quot;rbac.istio.io/v1alpha1&quot;
kind: ClusterRbacConfig
metadata:
name: default
namespace: istio-system
spec:
mode: ON_WITH_INCLUSION
inclusion:
namespaces: [ &quot;default&quot; ]
</code></pre>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
<th>Required</th>
</tr>
</thead>
<tbody>
<tr id="RbacConfig-mode">
<td><code>mode</code></td>
<td><code><a href="#RbacConfig-Mode">Mode</a></code></td>
<td>
<p>Istio RBAC mode.</p>
</td>
<td>
No
</td>
</tr>
<tr id="RbacConfig-inclusion">
<td><code>inclusion</code></td>
<td><code><a href="#RbacConfig-Target">Target</a></code></td>
<td>
<p>A list of services or namespaces that should be enforced by Istio RBAC policies. Note: This field have
effect only when mode is ON<em>WITH</em>INCLUSION and will be ignored for any other modes.</p>
</td>
<td>
No
</td>
</tr>
<tr id="RbacConfig-exclusion">
<td><code>exclusion</code></td>
<td><code><a href="#RbacConfig-Target">Target</a></code></td>
<td>
<p>A list of services or namespaces that should not be enforced by Istio RBAC policies. Note: This field have
effect only when mode is ON<em>WITH</em>EXCLUSION and will be ignored for any other modes.</p>
</td>
<td>
No
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="RbacConfig-Mode">RbacConfig.Mode</h2>
<section>
<table class="enum-values">
<thead>
<tr>
<th>Name</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr id="RbacConfig-Mode-OFF">
<td><code>OFF</code></td>
<td>
<p>Disable Istio RBAC completely, Istio RBAC policies will not be enforced.</p>
</td>
</tr>
<tr id="RbacConfig-Mode-ON">
<td><code>ON</code></td>
<td>
<p>Enable Istio RBAC for all services and namespaces. Note Istio RBAC is deny-by-default
which means all requests will be denied if it&rsquo;s not allowed by RBAC rules.</p>
</td>
</tr>
<tr id="RbacConfig-Mode-ON_WITH_INCLUSION">
<td><code>ON_WITH_INCLUSION</code></td>
<td>
<p>Enable Istio RBAC only for services and namespaces specified in the inclusion field. Any other
services and namespaces not in the inclusion field will not be enforced by Istio RBAC policies.</p>
</td>
</tr>
<tr id="RbacConfig-Mode-ON_WITH_EXCLUSION">
<td><code>ON_WITH_EXCLUSION</code></td>
<td>
<p>Enable Istio RBAC for all services and namespaces except those specified in the exclusion field. Any other
services and namespaces not in the exclusion field will be enforced by Istio RBAC policies.</p>
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="RbacConfig-Target">RbacConfig.Target</h2>
<section>
<p>Target defines a list of services or namespaces.</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
<th>Required</th>
</tr>
</thead>
<tbody>
<tr id="RbacConfig-Target-services">
<td><code>services</code></td>
<td><code>string[]</code></td>
<td>
<p>A list of services.</p>
</td>
<td>
No
</td>
</tr>
<tr id="RbacConfig-Target-namespaces">
<td><code>namespaces</code></td>
<td><code>string[]</code></td>
<td>
<p>A list of namespaces.</p>
</td>
<td>
No
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="RoleRef">RoleRef</h2>
<section>
<p>RoleRef refers to a role object.</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
<th>Required</th>
</tr>
</thead>
<tbody>
<tr id="RoleRef-kind">
<td><code>kind</code></td>
<td><code>string</code></td>
<td>
<p>The type of the role being referenced.
Currently, &ldquo;ServiceRole&rdquo; is the only supported value for &ldquo;kind&rdquo;.</p>
</td>
<td>
Yes
</td>
</tr>
<tr id="RoleRef-name">
<td><code>name</code></td>
<td><code>string</code></td>
<td>
<p>The name of the ServiceRole object being referenced.
The ServiceRole object must be in the same namespace as the ServiceRoleBinding object.</p>
</td>
<td>
Yes
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="ServiceRole">ServiceRole</h2>
<section>
<p>ServiceRole specification contains a list of access rules (permissions).</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
<th>Required</th>
</tr>
</thead>
<tbody>
<tr id="ServiceRole-rules">
<td><code>rules</code></td>
<td><code><a href="#AccessRule">AccessRule[]</a></code></td>
<td>
<p>The set of access rules (permissions) that the role has.</p>
</td>
<td>
Yes
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="ServiceRoleBinding">ServiceRoleBinding</h2>
<section>
<p>ServiceRoleBinding assigns a ServiceRole to a list of subjects.</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
<th>Required</th>
</tr>
</thead>
<tbody>
<tr id="ServiceRoleBinding-subjects">
<td><code>subjects</code></td>
<td><code><a href="#Subject">Subject[]</a></code></td>
<td>
<p>List of subjects that are assigned the ServiceRole object.</p>
</td>
<td>
Yes
</td>
</tr>
<tr id="ServiceRoleBinding-roleRef">
<td><code>roleRef</code></td>
<td><code><a href="#RoleRef">RoleRef</a></code></td>
<td>
<p>Reference to the ServiceRole object.</p>
</td>
<td>
Yes
</td>
</tr>
</tbody>
</table>
</section>
<h2 id="Subject">Subject</h2>
<section>
<p>Subject defines an identity. The identity is either a user or identified by a set of <code>properties</code>.
The supported keys in <code>properties</code> are listed in &ldquo;constraint and properties&rdquo; page.</p>
<table class="message-fields">
<thead>
<tr>
<th>Field</th>
<th>Type</th>
<th>Description</th>
<th>Required</th>
</tr>
</thead>
<tbody>
<tr id="Subject-user">
<td><code>user</code></td>
<td><code>string</code></td>
<td>
<p>Optional. The user name/ID that the subject represents.</p>
</td>
<td>
No
</td>
</tr>
<tr id="Subject-properties">
<td><code>properties</code></td>
<td><code>map&lt;string,&nbsp;string&gt;</code></td>
<td>
<p>Optional. The set of properties that identify the subject.</p>
</td>
<td>
No
</td>
</tr>
</tbody>
</table>
</section>