Today, you can extend the UI to add components that help make resources easier to understand.
I'd like to go beyond that, specifically in our case, which is to surface telemetery.
We cannot put telemetry into a CRD because etcd is not design for the kind of churn updating the CRD would produce. Nor in etcd a time-series database.
We want the benefits of the UI - i.e. SSO, RBAC, etc.
This is also how I'd envisage this for Argo CD. Essentially we extend ArgoCDExtension to support the proxy route.
I'm not sure we'd step on Backstages toes here, because we would not do anything with CI, docs, or the like, but it opens up these kinds of deep integrations:
Splunk
PagerDuty
Prometheus
Wavefront
OpenTelemetry
Druid
We need to consider the likely action of threat-actors for extensions. I would assume that the API server is the primary attack surface for Argo CD. So we should plan for the following:
DoS attacks (including the accidental kind that automation will do).
Sandbox escape - i.e. the user tries to look at data from another user.
DoS will need to be mitigated by rate limiter within the API server.
For RBAC, we have options:
Extend the Project model for extensions.
Delegate RBAC to the extenison itself, by providing enough information in headers for the extension to make the decision.
The second option makes more sense to me. Argo CD does not understand the resources of the proxied request, nor does it understand context or nature of the operation.
Today, you can extend the UI to add components that help make resources easier to understand.
I'd like to go beyond that, specifically in our case, which is to surface telemetery.
We cannot put telemetry into a CRD because etcd is not design for the kind of churn updating the CRD would produce. Nor in etcd a time-series database.
We want the benefits of the UI - i.e. SSO, RBAC, etc.
Backstage has a feature similar to this - "plugins": https://backstage.io/plugins
This is also how I'd envisage this for Argo CD. Essentially we extend
ArgoCDExtension
to support the proxy route.I'm not sure we'd step on Backstages toes here, because we would not do anything with CI, docs, or the like, but it opens up these kinds of deep integrations:
We need to consider the likely action of threat-actors for extensions. I would assume that the API server is the primary attack surface for Argo CD. So we should plan for the following:
DoS will need to be mitigated by rate limiter within the API server.
For RBAC, we have options:
Project
model for extensions.The second option makes more sense to me. Argo CD does not understand the resources of the proxied request, nor does it understand context or nature of the operation.