Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: add IRSA usage doc #1293

Merged
merged 1 commit into from
Apr 19, 2024
Merged

chore: add IRSA usage doc #1293

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
36 changes: 36 additions & 0 deletions docs/content/en/tasks/backup-restore/_index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -155,6 +155,42 @@ spec:
...
```

## Using IRSA (IAM Roles for Service Accounts) to Attribute Permissions to Medusa (AWS Only)

Simply use `role-based` as the `credentialsType`.


```yaml
apiVersion: k8ssandra.io/v1alpha1
kind: K8ssandraCluster
metadata:
name: demo
spec:
cassandra:
...
medusa:
medusaConfigurationRef:
name: medusaconfiguration-s3
storageProperties:
prefix: demo
credentialsType: role-based
storageSecretRef:
name: ""
...
```

To make this work, you must ensure the following steps are completed:

> While Medusa is running in standalone mode, it uses the default service account from the namespace. Make sure this service account has the necessary role annotation.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this behavior acceptable ?
That means that the default service account needs to be properly annotated and needs to be properly bound with the AWS IAM role.

Therefore, any pods created without a SA specified will be granted with AWS permissions.
This against the least privilege principle - many of our customers won't accept this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Following this, just opened this issue #1294

Copy link
Contributor Author

@JBOClara JBOClara Apr 19, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Totally agree, in my case, my project is not yet in production, so we have accepted the risk.
However, it is essential to be able to specify a specific "ServiceAccount" for Medusa standalone.

Each component should have complete customization of its spec.

> This means that the service account should have the necessary permissions to write to the backup bucket. Every pod using the default service account will inherit the same permissions.

- Ensure that Medusa is running with a specific Kubernetes service account.
- This Kubernetes service account should be annotated with the IAM Role ARN annotation for IRSA.
- This IAM role should have the permissions to write to the backup bucket.
- This role should have a trusted policy that allows it to assume a role with web identity, with a condition based on the namespace and Kubernetes service account name (refer to the AWS Documentation).
- Your Kubernetes cluster should have a correctly configured IAM OIDC provider. More information can be found [here](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html).
- This OIDC provider should be used in the trusted policy.

## Creating a Backup

To perform a backup of a Cassandra datacenter, create the following custom resource in the same namespace and Kubernetes cluster as the CassandraDatacenter resource, `cassandradatacenter/dc1` in this case :
Expand Down
Loading