LogoLogo
5.0.X
5.0.X
  • About Trilio for Kubernetes
    • Welcome to Trilio For Kubernetes
    • Version 5.0.X Release Highlights
    • Compatibility Matrix
    • Marketplace Support
    • Features
    • Use Cases
  • Getting Started
    • Getting Started with Trilio on Red Hat OpenShift (OCP)
    • Getting Started with Trilio for Upstream Kubernetes (K8S)
    • Getting Started with Trilio for AWS Elastic Kubernetes Service (EKS)
    • Getting Started with Trilio on Google Kubernetes Engine (GKE)
    • Getting Started with Trilio on VMware Tanzu Kubernetes Grid (TKG)
    • More Trilio Supported Kubernetes Distributions
      • General Installation Prerequisites
      • Rancher Deployments
      • Azure Cloud AKS
      • Digital Ocean Cloud
      • Mirantis Kubernetes Engine
      • IBM Cloud
    • Licensing
    • Using Trilio
      • Overview
      • Post-Install Configuration
      • Management Console
        • About the UI
        • Navigating the UI
          • UI Login
          • Cluster Management (Home)
          • Backup & Recovery
            • Namespaces
              • Namespaces - Actions
              • Namespaces - Bulk Actions
            • Applications
              • Applications - Actions
              • Applications - Bulk Actions
            • Virtual Machines
              • Virtual Machine -Actions
              • Virtual Machine - Bulk Actions
            • Backup Plans
              • Create Backup Plans
              • Backup Plans - Actions
            • Targets
              • Create New Target
              • Targets - Actions
            • Hooks
              • Create Hook
              • Hooks - Actions
            • Policies
              • Create Policies
              • Policies - Actions
          • Monitoring
          • Guided Tours
        • UI How-to Guides
          • Multi-Cluster Management
          • Creating Backups
            • Pause Schedule Backups and Snapshots
            • Cancel InProgress Backups
            • Cleanup Failed Backups
          • Restoring Backups & Snapshots
            • Cross-Cluster Restores
            • Namespace & application scoped
            • Cluster scoped
          • Disaster Recovery Plan
          • Continuous Restore
      • Command-Line Interface
        • YAML Examples
        • Trilio Helm Operator Values
    • Upgrade
    • Air-Gapped Installations
    • Uninstall
  • Reference Guides
    • T4K Pod/Job Capabilities
      • Resource Quotas
    • Trilio Operator API Specifications
    • Custom Resource Definition - Application
  • Advanced Configuration
    • AWS S3 Target Permissions
    • Management Console
      • KubeConfig Authenticaton
      • Authentication Methods Via Dex
      • UI Authentication
      • RBAC Authentication
      • Configuring the UI
    • Resource Request Requirements
      • Fine Tuning Resource Requests and Limits
    • Observability
      • Observability of Trilio with Prometheus and Grafana
      • Exported Prometheus Metrics
      • Observability of Trilio with Openshift Monitoring
      • T4K Integration with Observability Stack
    • Modifying Default T4K Configuration
  • T4K Concepts
    • Supported Application Types
    • Support for Helm Releases
    • Support for OpenShift Operators
    • T4K Components
    • Backup and Restore Details
      • Immutable Backups
      • Application Centric Backups
    • Retention Process
      • Retention Use Case
    • Continuous Restore
      • Architecture and Concepts
  • Performance
    • S3 as Backup Target
      • T4K S3 Fuse Plugin performance
    • Measuring Backup Performance
  • Ecosystem
    • T4K Integration with Slack using BotKube
    • Monitoring T4K Logs using ELK Stack
    • Rancher Navigation Links for Trilio Management Console
    • Optimize T4K Backups with StormForge
    • T4K GitHub Runner
    • AWS RDS snapshots using T4K hooks
    • Deploying Trilio For Kubernetes with Openshift ACM Policies
  • Krew Plugins
    • T4K QuickStart Plugin
    • Trilio for Kubernetes Preflight Checks Plugin
    • T4K Log Collector Plugin
    • T4K Cleanup Plugin
  • Support
    • Troubleshooting Guide
    • Known Issues and Workarounds
    • Contacting Support
  • Appendix
    • Ignored Resources
    • OpenSource Software Disclosure
    • CSI Drivers
      • Installing VolumeSnapshot CRDs
      • Install AWS EBS CSI Driver
    • T4K Product Quickview
    • OpenShift OperatorHub Custom CatalogSource
      • Custom CatalogSource in a restricted environment
    • Configure OVH Object Storage as a Target
    • Connect T4K UI hosted with HTTPS to another cluster hosted with HTTP or vice versa
    • Fetch DigitalOcean Kubernetes Cluster kubeconfig for T4K UI Authentication
    • Force Update T4K Operator in Rancher Marketplace
    • Backup and Restore Virtual Machines running on OpenShift
    • T4K For Volumes with Generic Storage
    • T4K Best Practices
Powered by GitBook
On this page

Was this helpful?

  1. Advanced Configuration

AWS S3 Target Permissions

Permissions required to add S3 as a target to T4K

PreviousCustom Resource Definition - ApplicationNextManagement Console

Last updated 2 months ago

Was this helpful?

To add AWS S3 (object storage) as a Target within T4K, users need specific access permissions on the bucket.

  • Implementation Step

    1. Create the following Policy in AWS

      • Note: replace bucketname with name of the s3 bucket name

      {
          "Version": "2012-10-17",
          "Statement": [
              {
                  "Effect": "Allow",
                  "Action": [
                      "s3:ListBucket",
                      "s3:PutObject",
                      "s3:GetObject",
                      "s3:DeleteObject"
                  ],
                  "Resource": [
                      "arn:aws:s3:::bucketname",
                      "arn:aws:s3:::bucketname/*"
                  ]
              },
              {
                  "Effect": "Deny",
                  "NotAction": "s3:*",
                  "NotResource": [
                      "arn:aws:s3:::bucketname",
                      "arn:aws:s3:::bucketname/*"
                  ]
              }
          ]
      }
    2. Attach policy to a user and collect the Access key ID ,Secret access key which the user has to provide while adding an AWS target.

    3. Optional: In case an AWS policy has been attached to a bucket then the bucket policy should be as follows:

      • Note: Alice is user in root account 111122223333

      {
          "Version": "2012-10-17",
          "Statement": [
              {
                  "Effect": "Allow",
                  "Principal": {
                  "AWS": [
                          "arn:aws:iam::111122223333:user/Alice",
                  ]
                  },
                  "Action": [                        
                      "s3:ListBucket",
                      "s3:PutObject",
                      "s3:GetObject",
                      "s3:DeleteObject"
                     ],
                  "Resource": [
                      "arn:aws:s3:::my_bucket",
                      "arn:aws:s3:::my_bucket/*"
                  ]
              }
          ]
      }
  • Security Settings:

    1. To perform target browsing, privileged containers are required for both object storage and NFS storage. Refer to the official documentation:

    2. If user has restricted privileged containers across backup and/or restore namespaces. PodSecurityPolicy should be edited to allow privileged containers. Create or edit the PodSecurityPolicy with the necessary privileges. Save this configuration in a YAML file, for example, allow-privileged-psp.yaml:

    apiVersion: policy/v1beta1
    kind: PodSecurityPolicy
    metadata:
      name: allow-privileged
    spec:
      privileged: true
    1. Apply or update the PodSecurityPolicy in your cluster:

    kubectl apply -f allow-privileged-psp.yaml
    1. Next, create a ClusterRole that allows the use of the PodSecurityPolicy:

    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
      name: use-allow-privileged-psp
    rules:
    - apiGroups: ['policy']
      resources: ['podsecuritypolicies']
      verbs: ['use']
      resourceNames: ['allow-privileged']  # Use the name of your PSP
    1. Apply the ClusterRole to your cluster:

    kubectl apply -f cluster-role.yaml
    1. Create a ClusterRoleBinding to bind the ClusterRole to the backup-namespace where you want to allow privileged containers:

    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRoleBinding
    metadata:
      name: bind-allow-privileged-psp
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: use-allow-privileged-psp  # Use the name of your ClusterRole
    subjects:
    - kind: ServiceAccount
      name: default  # Use the appropriate ServiceAccount name or account that you want to apply the PSP to
      namespace: backup-namespace  # Specify the target namespace
    1. Apply the ClusterRoleBinding to your cluster:

    kubectl apply -f cluster-role-binding.yaml

Make sure to adapt the configuration to your specific use case and security requirements. Please consult your system administrator before updating the PodSecurityPolicy.

Pod Security Context