Skip to content
Merged
Show file tree
Hide file tree
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
151 changes: 122 additions & 29 deletions docs/configuration/metric-providers-aws.rst
Original file line number Diff line number Diff line change
Expand Up @@ -6,25 +6,80 @@ Configure Robusta to use Amazon Managed Prometheus (AMP).
Prerequisites
-------------

1. An Amazon Managed Prometheus workspace
2. AWS access credentials (Access Key and Secret Key)
Before configuring Robusta with AWS Managed Prometheus, ensure you have:

1. **An Amazon Managed Prometheus (AMP) workspace**
See: `Getting started with Amazon Managed Service for Prometheus <https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-getting-started.html>`_.

2. **For IRSA**: Your EKS cluster must have an OIDC identity provider configured.
See: `Associate IAM OIDC Provider <https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html>`_.

3. **AWS access credentials (Access Key and Secret Key)**
With sufficient permissions to query AMP (for example, the ``AmazonPrometheusQueryAccess`` policy).

Comment thread
Avi-Robusta marked this conversation as resolved.
IRSA (Recommended)
------------------

IRSA (IAM Roles for Service Accounts) is the recommended way to authenticate Robusta with AWS Managed Prometheus.
With IRSA, you don’t need to manage long-lived AWS access keys — credentials are securely provided to pods via Kubernetes service accounts.

.. dropdown:: AWS Setup for IRSA
:animate: fade-in-slide-down

1. **Ensure your EKS cluster has an OIDC provider associated**:
See the AWS guide: `Associate IAM OIDC Provider <https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html>`_.

2. **Create an IAM role for Prometheus access with the correct trust policy**:
The role must include:

- The managed policy ``AmazonPrometheusQueryAccess`` (or equivalent custom policy).
- A trust policy allowing ``sts:AssumeRoleWithWebIdentity`` from your cluster’s OIDC provider.

Example trust policy (replace placeholders accordingly):

.. code-block:: json

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::<ACCOUNT_ID>:oidc-provider/oidc.eks.<REGION>.amazonaws.com/id/<OIDC_ID>"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"oidc.eks.<REGION>.amazonaws.com/id/<OIDC_ID>:sub": "system:serviceaccount:<NAMESPACE>:<SERVICE_ACCOUNT_NAME>"
}
}
}
]
}
Comment thread
Avi-Robusta marked this conversation as resolved.

Quick Start
-----------
~~~~~~~~~~~

1. **Create AWS credentials** if you don't have them:

Follow the `AWS guide <https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey>`_ to create an access key.
1. **Annotate Robusta service accounts** in the namespace where you installed the Helm chart.
At minimum, these two are critical:

2. **Store credentials in Kubernetes**:
- ``robusta-runner-service-account``
- ``robusta-holmes-service-account``

Example:

.. code-block:: yaml

.. code-block:: bash
runnerServiceAccount:
annotations:
eks.amazonaws.com/role-arn: arn:aws:iam::<ACCOUNT_ID>:role/<AMP_IAM_ROLE>

kubectl create secret generic aws-secret-key -n robusta \
--from-literal=access-key=YOUR_ACCESS_KEY \
--from-literal=secret-key=YOUR_SECRET_ACCESS_KEY
holmes:
serviceAccount:
annotations:
eks.amazonaws.com/role-arn: arn:aws:iam::<ACCOUNT_ID>:role/<AMP_IAM_ROLE>

Comment thread
Avi-Robusta marked this conversation as resolved.
3. **Configure Robusta** - add to ``generated_values.yaml``:
2. **Configure Robusta** - add to ``generated_values.yaml``:

.. code-block:: yaml

Expand All @@ -36,32 +91,73 @@ Quick Start
additional_env_vars:
- name: PROMETHEUS_SSL_ENABLED
value: "true"
- name: AWS_ACCESS_KEY
valueFrom:
secretKeyRef:
name: aws-secret-key
key: access-key
- name: AWS_SECRET_ACCESS_KEY
valueFrom:
secretKeyRef:
name: aws-secret-key
key: secret-key
- name: AWS_SERVICE_NAME
value: "aps"
- name: AWS_REGION
value: "us-east-1" # Your workspace region

4. :ref:`Update Robusta <Simple Upgrade>`
3. :ref:`Update Robusta <Simple Upgrade>`

Access Keys (Alternative)
-------------------------

If you prefer not to use IRSA, you can authenticate with long-lived AWS access keys.

.. dropdown:: AWS Setup for Access Keys
:animate: fade-in-slide-down
:icon: key

1. **Create AWS credentials** if you don't have them:
Follow the `AWS guide <https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey>`_ to create an access key.

2. **Store credentials in Kubernetes**:

.. code-block:: bash

kubectl create secret generic aws-secret-key -n robusta \
--from-literal=access-key=YOUR_ACCESS_KEY \
--from-literal=secret-key=YOUR_SECRET_ACCESS_KEY

3. **Configure Robusta** - add to ``generated_values.yaml``:

.. code-block:: yaml

globalConfig:
prometheus_url: "https://aps-workspaces.us-east-1.amazonaws.com/workspaces/ws-12345678"
check_prometheus_flags: false # Required for AWS

runner:
additional_env_vars:
- name: PROMETHEUS_SSL_ENABLED
value: "true"
- name: AWS_ACCESS_KEY
valueFrom:
secretKeyRef:
name: aws-secret-key
key: access-key
- name: AWS_SECRET_ACCESS_KEY
valueFrom:
secretKeyRef:
name: aws-secret-key
key: secret-key
- name: AWS_SERVICE_NAME
value: "aps"
- name: AWS_REGION
value: "us-east-1" # Your workspace region

4. :ref:`Update Robusta <Simple Upgrade>`

Finding Your Workspace URL
--------------------------
~~~~~~~~~~~~~~~~~~~~~~~~~~

1. Open the AWS Console
2. Navigate to Amazon Managed Service for Prometheus
3. Select your workspace
4. Copy the **Workspace endpoint URL**
5. Your prometheus_url is: ``<endpoint-url>``

---

Configuration Details
---------------------

Expand All @@ -71,8 +167,6 @@ Configuration Details
- ``AWS_SERVICE_NAME``: Always ``"aps"`` for Amazon Prometheus Service
- ``AWS_REGION``: The AWS region where your workspace is located



Important Notes
---------------

Expand All @@ -81,13 +175,12 @@ Important Notes
AWS Managed Prometheus does not support the Prometheus flags API. Always set ``check_prometheus_flags: false``.

- AlertManager URL is not needed (AWS handles alerting separately)
- Ensure your AWS credentials have permissions to query the AMP workspace
- Ensure your IAM role or AWS credentials have permissions to query the AMP workspace
- The workspace must be in the same region specified in AWS_REGION


Next Steps
----------

- Configure :doc:`alert routing </notification-routing/index>`
- Set up ingestion from your cluster to AMP
- Learn about :doc:`common configuration options <metric-providers>`
- Learn about :doc:`common configuration options <metric-providers>`
33 changes: 17 additions & 16 deletions playbooks/robusta_playbooks/krr.py
Original file line number Diff line number Diff line change
Expand Up @@ -276,22 +276,23 @@ def _generate_prometheus_secrets(prom_config: PrometheusConfig) -> List[KRRSecre
)

if isinstance(prom_config, AWSPrometheusConfig):
krr_secrets.extend(
[
KRRSecret(
env_var_name="AWS_KEY",
secret_key="aws-key",
secret_value=prom_config.access_key,
command_flag="--eks-access-key",
),
KRRSecret(
env_var_name="AWS_SECRET",
secret_key="aws-secret",
secret_value=prom_config.secret_access_key,
command_flag="--eks-secret-key",
),
]
)
if prom_config.access_key and prom_config.secret_access_key:
krr_secrets.extend(
[
KRRSecret(
env_var_name="AWS_KEY",
secret_key="aws-key",
secret_value=prom_config.access_key,
command_flag="--eks-access-key",
),
KRRSecret(
env_var_name="AWS_SECRET",
secret_key="aws-secret",
secret_value=prom_config.secret_access_key,
command_flag="--eks-secret-key",
),
]
)
if isinstance(prom_config, CoralogixPrometheusConfig):
krr_secrets.append(
KRRSecret(
Expand Down
Loading
Loading