Alerting: Add two sets of provisioning actions for rules and notifications

[yuri-tceretian]

What is this feature?
This PR adds two new sets of permissions that let administrators create custom roles to grant access to provisioning alert rules and notification configurations separately.
It does not replace already existing permissions.

Why do we need this feature?
To allow Grafana Enterprise users to grant access to rules API but not notifications provisioning APIs

Who is this feature for?

Special notes for your reviewer:
The new actions are not exposed independently. To test, you need to create a new custom role.

Example API Call

curl --location 'http://localhost:3000/api/access-control/roles' \
--header 'Content-Type: application/json' \
--header 'Authorization: Basic YWRtaW46YWRtaW4=' \
--data '{
    "version": 1,
    "name": "custom:alerting_rule_provisioner",
    "displayName": "Alert Rules Provisioner",
    "description": "Access only alert rule provisioning API",
    "group":"Alerting",
    "permissions": [
        {
            "action": "alert.rules.provisioning:read"
        },
        {
            "action": "alert.rules.provisioning:write"
        }
    ]
}
'

Then you can create a test user

Example API Call

curl --location 'http://localhost:3000/api/admin/users' \
--header 'Content-Type: application/json' \
--header 'Authorization: Basic YWRtaW46YWRtaW4=' \
--data-raw '{
    "name": "test",
    "email": "test@example.com",
    "login": "test",
    "password": "test"
}'

and then assign the new role to the user (user Id and role UID need to be replaced with values from responses)

Example API Call

curl --location --request PUT 'http://localhost:3000/api/access-control/users/2/roles' \
--header 'Content-Type: application/json' \
--header 'Authorization: Basic YWRtaW46YWRtaW4=' \
--data '{"orgId":1,"roleUids":["bdl6zemr9r9xcd"]}'

Please check that:

• It works as expected from a user's perspective.
• If this is a pre-GA feature, it is behind a feature toggle.
• The docs are updated, and if this is a notable improvement, it's added to our What's New doc.

[grafana-delivery-bot]

Hello @yuri-tceretian!
Backport pull requests need to be either:

• Pull requests which address bugs,
• Urgent fixes which need product approval, in order to get merged,
• Docs changes.

Please, if the current pull request addresses a bug fix, label it with the type/bug label.
If it already has the product approval, please add the product-approved label. For docs changes, please add the type/docs label.
If the pull request modifies CI behaviour, please add the type/ci label.
If none of the above applies, please consider removing the backport label and target the next major/minor release.
Thanks!

[grafana-delivery-bot]

Hello @yuri-tceretian!
Backport pull requests need to be either:

• Pull requests which address bugs,
• Urgent fixes which need product approval, in order to get merged,
• Docs changes.

Please, if the current pull request addresses a bug fix, label it with the type/bug label.
If it already has the product approval, please add the product-approved label. For docs changes, please add the type/docs label.
If the pull request modifies CI behaviour, please add the type/ci label.
If none of the above applies, please consider removing the backport label and target the next major/minor release.
Thanks!

[grafana-delivery-bot]

Hello @yuri-tceretian!
Backport pull requests need to be either:

• Pull requests which address bugs,
• Urgent fixes which need product approval, in order to get merged,
• Docs changes.

Please, if the current pull request addresses a bug fix, label it with the type/bug label.
If it already has the product approval, please add the product-approved label. For docs changes, please add the type/docs label.
If the pull request modifies CI behaviour, please add the type/ci label.
If none of the above applies, please consider removing the backport label and target the next major/minor release.
Thanks!

[grafana-delivery-bot]

Hello @yuri-tceretian!
Backport pull requests need to be either:

• Pull requests which address bugs,
• Urgent fixes which need product approval, in order to get merged,
• Docs changes.

Please, if the current pull request addresses a bug fix, label it with the type/bug label.
If it already has the product approval, please add the product-approved label. For docs changes, please add the type/docs label.
If the pull request modifies CI behaviour, please add the type/ci label.
If none of the above applies, please consider removing the backport label and target the next major/minor release.
Thanks!

[JacobsonMT]

LGTM 🚀

[ryan-grafana]

Approved for backport

[grafana-delivery-bot]

This PR must be merged before a backport PR will be created.

[rwwiv]

👍

[grafana-delivery-bot]

The backport to v10.2.x failed:

The process '/usr/bin/git' failed with exit code 1

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new branch
git switch --create backport-87149-to-v10.2.x origin/v10.2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x 356a29592be6c5fe5de81138f6a55e03a8cdfac2

When the conflicts are resolved, stage and commit the changes:

git add . && git cherry-pick --continue

If you have the GitHub CLI installed:

# Push the branch to GitHub:
git push --set-upstream origin backport-87149-to-v10.2.x
# Create the PR body template
PR_BODY=$(gh pr view 87149 --json body --template 'Backport 356a29592be6c5fe5de81138f6a55e03a8cdfac2 from #87149{{ "\n\n---\n\n" }}{{ index . "body" }}')
# Create the PR on GitHub
echo "${PR_BODY}" | gh pr create --title "[v10.2.x] Alerting: Add two sets of provisioning actions for rules and notifications " --body-file - --label "area/alerting" --label "area/backend" --label "add to changelog" --label "area/auth/rbac" --label "product-approved" --label "backport" --base v10.2.x --milestone 10.2.x --web

Or, if you don't have the GitHub CLI installed (we recommend you install it!):

# Push the branch to GitHub:
git push --set-upstream origin backport-87149-to-v10.2.x

# Create a pull request where the `base` branch is `v10.2.x` and the `compare`/`head` branch is `backport-87149-to-v10.2.x`.

# Remove the local backport branch
git switch main
git branch -D backport-87149-to-v10.2.x

[grafana-delivery-bot]

The backport to v10.3.x failed:

The process '/usr/bin/git' failed with exit code 1

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new branch
git switch --create backport-87149-to-v10.3.x origin/v10.3.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x 356a29592be6c5fe5de81138f6a55e03a8cdfac2

When the conflicts are resolved, stage and commit the changes:

git add . && git cherry-pick --continue

If you have the GitHub CLI installed:

# Push the branch to GitHub:
git push --set-upstream origin backport-87149-to-v10.3.x
# Create the PR body template
PR_BODY=$(gh pr view 87149 --json body --template 'Backport 356a29592be6c5fe5de81138f6a55e03a8cdfac2 from #87149{{ "\n\n---\n\n" }}{{ index . "body" }}')
# Create the PR on GitHub
echo "${PR_BODY}" | gh pr create --title "[v10.3.x] Alerting: Add two sets of provisioning actions for rules and notifications " --body-file - --label "area/alerting" --label "area/backend" --label "add to changelog" --label "area/auth/rbac" --label "product-approved" --label "backport" --base v10.3.x --milestone 10.3.x --web

Or, if you don't have the GitHub CLI installed (we recommend you install it!):

# Push the branch to GitHub:
git push --set-upstream origin backport-87149-to-v10.3.x

# Create a pull request where the `base` branch is `v10.3.x` and the `compare`/`head` branch is `backport-87149-to-v10.3.x`.

# Remove the local backport branch
git switch main
git branch -D backport-87149-to-v10.3.x

[grafana-delivery-bot]

The backport to v10.4.x failed:

The process '/usr/bin/git' failed with exit code 1

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new branch
git switch --create backport-87149-to-v10.4.x origin/v10.4.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x 356a29592be6c5fe5de81138f6a55e03a8cdfac2

When the conflicts are resolved, stage and commit the changes:

git add . && git cherry-pick --continue

If you have the GitHub CLI installed:

# Push the branch to GitHub:
git push --set-upstream origin backport-87149-to-v10.4.x
# Create the PR body template
PR_BODY=$(gh pr view 87149 --json body --template 'Backport 356a29592be6c5fe5de81138f6a55e03a8cdfac2 from #87149{{ "\n\n---\n\n" }}{{ index . "body" }}')
# Create the PR on GitHub
echo "${PR_BODY}" | gh pr create --title "[v10.4.x] Alerting: Add two sets of provisioning actions for rules and notifications " --body-file - --label "area/alerting" --label "area/backend" --label "add to changelog" --label "area/auth/rbac" --label "product-approved" --label "backport" --base v10.4.x --milestone 10.4.x --web

Or, if you don't have the GitHub CLI installed (we recommend you install it!):

# Push the branch to GitHub:
git push --set-upstream origin backport-87149-to-v10.4.x

# Create a pull request where the `base` branch is `v10.4.x` and the `compare`/`head` branch is `backport-87149-to-v10.4.x`.

# Remove the local backport branch
git switch main
git branch -D backport-87149-to-v10.4.x