As it stands right now, all-access tokens are provisioned that allow doing ANYTHING within the InfluxDB instance. I'd like to propose a bidirectional binding to restrict that scope.
InfluxDB Scope
We should allow the InfluxDB CRD to limit the scope (read/write/buckets) to any Token CRD applied by a Kubernetes end user. This allows the owner of the InfluxDB (the one that supplies the admin token) to restrict access on a per-namespace level.
apiVersion: influxdb.influxdata.com/v1
kind: InfluxDB
metadata:
name: influxdb-sample
spec:
provision: false
url: http://influxdb2.default
organization: 05a80639861e9000
token:
secretName: influxdb2-auth
secretKey: admin-token
scope:
- namespace: grafana
read:
- my_bucket
write: [] # An empty, or omitted, array means no requested access
- namespace: "*"
write:
- my_bucket
read: [] # An empty, or omitted, array means no requested access
Token Scope
This is primarily for pull requests and to be explicit about what scopes are needed by the calling application. We probably don't want to allow a "Give me whatever you got" scope, and instead require very explicit declarations. As our Operator will not be responsible for provisioning of buckets, these will all need created up-front anyway (so should be known).
apiVersion: influxdb.influxdata.com/v1
kind: Token
metadata:
name: token-sample
spec:
influxdb: influxdb-sample
secret: mytoken
scope:
read: [] # An empty, or omitted, array means no requested access
write:
- metrics_bucket
Now that we've pushed up the initial spike for token provisioning with InfluxDB v2, we need to discuss the next step: token scopes.
Currently our CRD looks like:
When we provision a
Token
, we provide a CRD such as:As it stands right now, all-access tokens are provisioned that allow doing ANYTHING within the InfluxDB instance. I'd like to propose a bidirectional binding to restrict that scope.
InfluxDB Scope
We should allow the InfluxDB CRD to limit the scope (read/write/buckets) to any Token CRD applied by a Kubernetes end user. This allows the owner of the InfluxDB (the one that supplies the admin token) to restrict access on a per-namespace level.
Token Scope
This is primarily for pull requests and to be explicit about what scopes are needed by the calling application. We probably don't want to allow a "Give me whatever you got" scope, and instead require very explicit declarations. As our Operator will not be responsible for provisioning of buckets, these will all need created up-front anyway (so should be known).