fix(docs): remove permitted annotation from docs

docs/api-overview.md

@@ -89,17 +89,10 @@ privileges. It will create/read/update secrets in all namespaces and has access
 to secrets stored in some external API. Ensure that the credentials you provide
 give ESO the least privilege necessary.
 
-Design your `SecretStore`/`ClusterSecretStore` carefully! Use annotations on
-namespaces to restrict access of application developers to read only certain
+Design your `SecretStore`/`ClusterSecretStore` carefully! Be sure to restrict
+access of application developers to read only certain
 keys in a shared environment.
 
-``` yaml
-{% include 'namespace-permitted-annotation.yaml' %}
-```
-
-!!! bug "Not implemented"
-    This is currently **not yet** implemented. Feel free to contribute.
-
 You should also consider using Kubernetes' admission control system (e.g.
 [OPA](https://www.openpolicyagent.org/) or [Kyverno](https://kyverno.io/)) for
 fine-grained access control.

docs/guides-multi-tenancy.md

@@ -28,16 +28,11 @@ to the external API. The CSS is shared by all tenants within the cluster.
 Application Developers do reference it in a `ExternalSecret` but can not create
 a ClusterSecretStores or SecretStores on their own. Now all application
 developers have access to all the secrets. You probably want to limit access to
-certain keys or prefixes that should be used. ESO provides a very simple
-mechanic to limit access to certain keys on a namespace basis by using
-annotations on the `Kind=Namespace` resource. More advanced validation should be
+certain keys or prefixes that should be used. ESO does not provide a mechanic
+to limit access to certain keys per namespace. More advanced validation should be
 done with an Admission Webhook, e.g. with [Kyverno](https://kyverno.io/) or
 [Open Policy Agent](https://www.openpolicyagent.org/)).
 
-``` yaml
-{% include 'namespace-permitted-annotation.yaml' %}
-```
-
 This setup suites well if you have one central bucket that contains all of your
 secrets and your Cluster Administrators should manage access to it. This setup
 is very simple but does not scale very well.

docs/snippets/namespace-permitted-annotation.yaml

@@ -1,8 +0,0 @@
-apiVersion: v1
-kind: Namespace
-metadata:
-  name: team-a
-  annotations:
-    # annotation that defines which keys can be read
-    # the annotation value is a regular expression
-    external-secrets.io/permitted-key-name: "a/development/*"

docs/snippets/provider-aws-access.md

@@ -7,18 +7,3 @@ Access to AWS providers can be granted in various ways:
 * Directly provide AWS credentials to the External Secrets Operator pod by using environment variables.
 
 Additionally, before fetching a secret from a store, ESO is able to assume role (as a proxy so to speak). It is advisable to use multiple roles in a multi-tenant environment.
-
-
-You can limit the range of roles which can be assumed by this particular namespace by using annotations on the namespace resource. The annotation value is evaluated as a regular expression.
-
-!!! bug "Not implemented"
-    This is currently **not** implemented. Feel free to contribute.
-
-``` yaml
-kind: Namespace
-metadata:
-  name: iam-example
-  annotations:
-    # annotation key is configurable
-    iam.amazonaws.com/permitted: "arn:aws:iam::123456789012:role/foo.*"
-```

docs/spec.md

@@ -838,7 +838,7 @@ ExternalSecretTemplateMetadata
 <td>
 <code>data</code></br>
 <em>
-map[string][]byte
+map[string]string
 </em>
 </td>
 <td>