[Local Dev Environment] Remove Anonymous Auth in local dev environmen… (#738)

Remove Anonymous Auth in local dev environment grafana instance, update
docs to reflect this change.

Related to #737, as the
anonymous role of `Admin` is being deprecated, and a `Viewer` anonymous
role doesn't show the plugin, so for ease-of-use anonymous auth will be
turned off. It can be re-enabled with the `Viewer` role via
`local/config.yaml` by adding
```
grafanaWithAnonymousAuth: true
```

We could also have `grafanaAnonymousAuth` be a string key that allows
for specifying a specific role, rather than an on/off switch, I have no
strong opinions on that, and would love any opinions on it.

Author: IfSentient

cmd/grafana-app-sdk/project_local.go

@@ -47,6 +47,7 @@ type localEnvConfig struct {
 	GenerateGrafanaDeployment bool                  `json:"generateGrafanaDeployment" yaml:"generateGrafanaDeployment"`
 	GrafanaImage              string                `json:"grafanaImage" yaml:"grafanaImage"`
 	GrafanaInstallPlugins     string                `json:"grafanaInstallPlugins" yaml:"grafanaInstallPlugins"`
+	GrafanaWithAnonymousAuth  bool                  `json:"grafanaWithAnonymousAuth" yaml:"grafanaWithAnonymousAuth"`
 }
 
 type dataSourceConfig struct {
@@ -320,6 +321,7 @@ type yamlGenProperties struct {
 	GenerateGrafanaDeployment bool
 	GrafanaImage              string
 	GrafanaInstallPlugins     string
+	GrafanaAnonymousAuth      string
 }
 
 type yamlGenPropsCRD struct {
@@ -391,6 +393,9 @@ func generateKubernetesYAML(crdGenFunc func() (codejen.Files, error), pluginID s
 		// Prefix with "localhost/" to ensure that our local build uses our locally-built image
 		props.OperatorImage = fmt.Sprintf("localhost/%s", props.OperatorImage)
 	}
+	if config.GrafanaWithAnonymousAuth {
+		props.GrafanaAnonymousAuth = "Viewer"
+	}
 
 	if props.WebhookProperties.Enabled {
 		if config.Webhooks.Port > 0 {

cmd/grafana-app-sdk/templates/local/generated/grafana.yaml

@@ -69,9 +69,10 @@ data:
     reporting_enabled = false
     [tracing.opentelemetry.otlp]
     address = tempo.default.svc:4317
-    [auth.anonymous]
+    [auth.anonymous]{{ if .GrafanaAnonymousAuth }}
     enabled = true
-    org_role = Admin
+    org_role = {{ .GrafanaAnonymousAuth }}{{ else }}
+    enabled = false{{ end }}
     [log.frontend]
     enabled = true
     [plugins]

docs/local-development.md

@@ -201,7 +201,9 @@ With those extra two steps done, you should now have a working local deployment.
 
 ## Accessing Your Deployment
 
-Once up, your local grafana can be accessed via [grafana.k3d.localhost:9999](http://grafana.k3d.localhost:9999) (if you used a `port` other than 9999 in your `local/config.yaml`, use that instead in the URL).
+Once up, your local grafana can be accessed via [grafana.k3d.localhost:9999](http://grafana.k3d.localhost:9999) (if you used a `port` other than 9999 in your `local/config.yaml`, use that instead in the URL). 
+The default username and password for the local grafana is `admin`/`admin`. 
+You can enable anonymous auth using a `Viewer` role by setting `grafanaWithAnonymousAuth: true` in `local/config.yaml`.
 
 If you use kubectl, your kubeconfig should have its default context changed to the local cluster, so you can get any resources that way.
 

docs/tutorials/issue-tracker/05-local-deployment.md

@@ -217,11 +217,19 @@ Though not recommended, you can deploy without using tilt, if you desire. Not us
 ### Interacting With Our Local Deployment
 
 Our grafana is now available at [grafana.k3d.localhost:9999](http://grafana.k3d.localhost:9999). 
+By default, the credentials to log in are `admin`/`admin`. You'll be prompted to change the password upon logging in. 
+Note that if you do, you'll need to modify the cURL commands used later in this tutorial. You can also click `Skip` to avoid updating the password. 
 Since our plugin is automatically installed, we can go to [grafana.k3d.localhost:9999/a/issuetrackerproject-app/](http://grafana.k3d.localhost:9999/a/issuetrackerproject-app/) and see the simple landing page that got generated for us, and we can interact with our backend APIs at [grafana.k3d.localhost:9999/api/plugins/issuetrackerproject-app/resources/v1/issues](http://grafana.k3d.localhost:9999/api/plugins/issuetrackerproject-app/resources/v1/issues).
 
 Right now, if I do a curl to our list endpoint, we'll get back a response with an empty list:
 ```shell
-$ curl http://grafana.k3d.localhost:9999/api/plugins/issuetrackerproject-app/resources/v1/issues | jq .
+curl -u admin:admin http://grafana.k3d.localhost:9999/api/plugins/issuetrackerproject-app/resources/v1/issues
+```
+> [!NOTE]
+> If you updated the password for your grafana instance, you'll need to change `-u admin:admin` to `-u admin:<your_new_password>`
+
+```shell
+$ curl -u admin:admin http://grafana.k3d.localhost:9999/api/plugins/issuetrackerproject-app/resources/v1/issues | jq .
 {
   "kind": "IssueList",
   "apiVersion": "issuetrackerproject.ext.grafana.com/v1",
@@ -235,7 +243,10 @@ $ curl http://grafana.k3d.localhost:9999/api/plugins/issuetrackerproject-app/res
 Our kinds are also available via the grafana API server, located at [http://grafana.k3d.localhost:9999/apis]. This is a kubernetes-compatible API server, and we can interact with it via cURL, or kubectl. 
 Let's also list our issues that way:
 ```shell
-curl http://grafana.k3d.localhost:9999/apis/issuetrackerproject.ext.grafana.com/v1/namespaces/default/issues
+curl -u admin:admin http://grafana.k3d.localhost:9999/apis/issuetrackerproject.ext.grafana.com/v1/namespaces/default/issues
+```
+```shell
+$ curl -u admin:admin http://grafana.k3d.localhost:9999/apis/issuetrackerproject.ext.grafana.com/v1/namespaces/default/issues
 {
   "apiVersion": "issuetrackerproject.ext.grafana.com/v1",
   "items": [],
@@ -249,7 +260,10 @@ curl http://grafana.k3d.localhost:9999/apis/issuetrackerproject.ext.grafana.com/
 We can see the output is nearly identical, as the plugin backend is just a proxy to the API server. From this point, we could use the plugin backend or API server API, 
 but seeing as the plugin backend will eventually be phased out of the default path, let's use the API server here, and create an Issue:
 ```shell
-$ curl -X POST -H "content-type:application/json" -d '{"kind":"Issue","apiVersion":"issuetrackerproject.ext.grafana.com/v1","metadata":{"name":"test-issue","namespace":"default"},"spec":{"title":"Test","description":"A test issue","status":"open"}}' http://grafana.k3d.localhost:9999/apis/issuetrackerproject.ext.grafana.com/v1/namespaces/default/issues
+curl -u admin:admin -X POST -H "content-type:application/json" -d '{"kind":"Issue","apiVersion":"issuetrackerproject.ext.grafana.com/v1","metadata":{"name":"test-issue","namespace":"default"},"spec":{"title":"Test","description":"A test issue","status":"open"}}' http://grafana.k3d.localhost:9999/apis/issuetrackerproject.ext.grafana.com/v1/namespaces/default/issues
+```
+```shell
+$ curl -u admin:admin -X POST -H "content-type:application/json" -d '{"kind":"Issue","apiVersion":"issuetrackerproject.ext.grafana.com/v1","metadata":{"name":"test-issue","namespace":"default"},"spec":{"title":"Test","description":"A test issue","status":"open"}}' http://grafana.k3d.localhost:9999/apis/issuetrackerproject.ext.grafana.com/v1/namespaces/default/issues
 {
   "apiVersion": "issuetrackerproject.ext.grafana.com/v1",
   "kind": "Issue",
@@ -291,6 +305,9 @@ You can see that this includes metadata which we didn't define in our CUE, but w
 
 For fun, we can also interact with our resources through kubectl:
 ```shell
+kubectl get issue test-issue -o yaml
+```
+```shell
 $ kubectl get issue test-issue -o yaml
 apiVersion: issuetrackerproject.ext.grafana.com/v1
 kind: Issue

docs/tutorials/issue-tracker/06-frontend.md

@@ -12,7 +12,7 @@ For this tutorial, we have one pre-written, that we'll discuss a few parts of. E
 mkdir -p plugin/src/api && curl -o plugin/src/api/issue_client.ts https://raw.githubusercontent.com/grafana/grafana-app-sdk/main/docs/tutorials/issue-tracker/frontend-files/issue-client.ts
 ```
 
-The client uses grafana libraries to make fetch requests to perform relevent actions, and uses the generated `Issue` type in `generated/issue/v1/issue_object_gen.ts` that mirrors our generated go `v1.Issue` type. We have methods for `get`, `list`, `create`, `update`, and `delete`. We'll use these methods in our update to the main page of the plugin.
+The client uses grafana libraries to make fetch requests to perform relevant actions, and uses the generated `Issue` type in `generated/issue/v1/issue_object_gen.ts` that mirrors our generated go `v1.Issue` type. We have methods for `get`, `list`, `create`, `update`, and `delete`. We'll use these methods in our update to the main page of the plugin.
 
 ## Main Page
 
@@ -92,11 +92,11 @@ That we'll use in our display output to show the correct Issue status and displa
 
 Now we want to redeploy our plugin front-end to see the changes. Since we don't need to rebuild the operator or the plugin's backend, we can just do
 ```bash
-$ make build/plugin-frontend
+make build/plugin-frontend
 ```
 After that completes, we can redploy to our active local environment with
 ```bash
-$ make local/deploy_plugin
+make local/deploy_plugin
 ```
 And just like that, we can refresh or go to [http://grafana.k3d.localhost:9999/a/issuetrackerproject-app/], and see our brand-new plugin UI. 
 If we create a new issue, we can see that it shows up in the list, or via a `kubectl get issues`.