dapr
dapr copied to clipboard
dapr
[Feature Request] Zero Trust mode for dapr
/area runtime
Problem space
The OOTB default scope configuration of some/most(?) build blocks are permissive.
A non-exhaustive list off the top of my head, to give a few examples...
- All secrets are exposed in the secret store by default.
- All secret stores are available to every App by default.
- All Apps can invoke each other by default.
- All components are available to all Apps.
This default scope configuration is somewhat going against the grain of how one might ensure a "zero trust" configuration.
Proposed feature
Provide a cluster-wide Dapr configuration option called "zero trust", which when enabled, runs Dapr in a mode where dapr-ised Apps have access to nothing by default.
This would enforce operators to ensure that all permissions are explicit/opt-in in the component CRDs & configurations, and provide the best approach for ensuring only the right Apps can access the allowed building blocks/components/items within components.
Bonus : Not my area of expertise here, so bare with me on this... I understand that Dapr doesn't directly compete with Service Meshes, however a big feature that is often touted by Service Meshes is the zero trust intrinsics. Therefore this feature may be an important factor to stakeholders who are on the fence on wether to use Dapr or Service Mesh, and are led/biased by security-conscious decision making?
Extension...
There may be orgs that are already using Dapr whom do not have strong/fully-formed scoping/opt-in policies, but have an aspiration to switch to a "zero trust" mode. This could be quite a challenging/lengthy process, as in, going through every App and building up the rules from scratch to be as restrictive as possible.
Question : So... by actively monitoring what component each sidecar is trying to access, could Dapr itself intelligently notify the human Operator for any missing explicit rules, that need reviewing?
This could manifest as a section in the Dapr Dashboard i.e. a 'Zero Trust Diagnosis' sub-section, that flags any missing explicit rules, and could even make a recommendation on what the YAML could be to resolve that particular missing rule.
Obviously the human Operator still needs to make a decision on wether each particular scenario represents correct/authorised usage of a particular component, but the point is that at least the human Operator is aware that something potentially unexpected/unplanned or nefarious is occurring which needs attention.
This would only make a difference in scenarios where the configuration for Dapr in the cluster is not done by the developers. Dapr does not have a concept of "Global Configuration" and each app specifies its own config at runtime. So, the production environment must have this configuration restricted to only admins. Then, we could offer a "zero trust" config where components are only accessible by opt-in (scopes) and so is service to service invocation.
@artursouza
Ok. Would it be possible to enable “zero trust” mode when dapr is installed into the cluster for the first time? Happy if this is an immutable option.
This issue has been automatically marked as stale because it has not had activity in the last 60 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had activity in the last 60 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.
This issue has been automatically closed because it has not had activity in the last 67 days. If this issue is still valid, please ping a maintainer and ask them to label it as pinned, good first issue, help wanted or triaged/resolved. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had activity in the last 60 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.
This issue has been automatically closed because it has not had activity in the last 67 days. If this issue is still valid, please ping a maintainer and ask them to label it as pinned, good first issue, help wanted or triaged/resolved. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had activity in the last 60 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.
This issue has been automatically closed because it has not had activity in the last 67 days. If this issue is still valid, please ping a maintainer and ask them to label it as pinned, good first issue, help wanted or triaged/resolved. Thank you for your contributions.