Forem: Asanka Boteju

Cluster Security Standards Enforcement Via Kyverno (Policy as Code)

Asanka Boteju — Tue, 29 Apr 2025 18:14:18 +0000

Kyverno, an open-source Kubernetes policy engine that lets you write policies as simple YAML manifests.

Kyverno has become increasingly important in today’s cloud-native world due to the growing adoption of Kubernetes and the increasing demand for security, compliance, and automation in cluster management.

Why Kyverno:

Security & Policy Enforcement
Today more and more organizations adopt Kubernetes, and managing multi-tenant clusters securely becomes critical. Kyverno helps you
Enforcing Pod Security Standards
-- Ensuring network policies are always defined
-- Preventing usage of deprecated APIs
Automated Governance & Compliance
Regulatory requirements such as GDPR and HIPAA need consistent policy enforcement. Kyverno helps you;
-- Automate auditing of non-compliant resources
-- Ensure labels, annotations, or resource limits are always set
-- Implement multi-cluster governance
-- Policy as Code, Kubernetes-Native
Unlike OPA/Gatekeeper, which uses a separate language—Rego, Kyverno
Uses Kubernetes-native YAML for policies.
-- Easier for K8s users to adopt
-- Policies look like other Kubernetes resources
-- Great fit for GitOps workflows such as ArgoCD and Flux
Mutation & Generation Capabilities
Kyverno can mutate and generate resources dynamically
-- Auto-inject sidecars/configurations
-- Generate default network policies/configmaps
-- Patch fields in newly created resources.
Validation at Admission Time Kyverno policies work with the Kubernetes Admission Controller to prevent invalid/non-compliant configurations before they go live.
-- Helps shift security and compliance left
-- Reduces production incidents due to misconfigurations
Multi-cloud, Multi-cluster Support With teams running hybrid environments across AWS, Azure, GCP, and on-prem, Kyverno ensures policy consistency across clusters.

Some of the cases we can use keyverno includes

Block the creation of privileged pods (a common security best practice)
Enforce resource requests/limits
Label enforcement for workloads

Time for some hands-on!

Lets see it in action with a simple demo to grasp the power of kyverno

Install Kyverno: run the below command in your terminal to install Kyverno

kubectl create -f https://raw.githubusercontent.com/kyverno/kyverno/main/config/release/install.yaml

Follow the below instructions to enforce resource requests and limits—this ensures that every container in a pod has CPU and memory requests and limits set.

require-resources.yaml

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-resources
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-resources
      match:
        resources:
          kinds:
            - Pod
      validate:
        message: "CPU and memory requests/limits must be set for all containers."
        foreach:
          - list: "spec.containers[]"
            pattern:
              resources:
                requests:
                  memory: "?*"
                  cpu: "?*"
                limits:
                  memory: "?*"
                  cpu: "?*"

Run the below command, which will apply the “require-resources” policy to your Kubernetes cluster.

kubectl apply -f require-resources.yaml

Okay, now run the below code block in your terminal to create a resource and test the policy enforcement in action.

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: no-resources
spec:
  containers:
    - name: nginx
      image: nginx
EOF

You should see an error message as shown in the above screen capture, which details the reason for the error.

Okay, now let's do this.

Now, let's add the resource limits and try the resource creation. For that, run the below code in your terminal.

You can see the resource created message, as now the resource you have created complies with the policy requirements.

Important — validationFailureAction
The **validationFailureAction** field in Kyverno policies determines how the policy behaves when a validation rule fails:

enforce: The policy will block the resource from being created or updated if it does not comply with the policy.

audit: The policy will allow the resource to be created or updated but will log a warning or violation in the policy report.

This is just one of the many possibilities of Kyverno policy enforcement, and you can explore those also in a similar fashion.

Hope the information is useful. Thank you for your time

An Intro To Generative AI Applications with Amazon Bedrock

Asanka Boteju — Wed, 22 Jan 2025 16:45:23 +0000

Amazon Bedrock is a managed service by AWS that helps you build and scale GenAI applications. Bedrock allows you to access FMs (foundation models) that are provided by AWS as well as any other third-party vendor-provided FMs via API calls. Some of the major FMs included in this ever-growing list are FMs such as Cohere and StabilityAI, Meta, AI21Labs, and Anthropic.

FMs are used as the baseline at the starting point of a model, which can be used to interpret and understand a language, converse in conversational messaging, and also to generate images based on your prompts.

Different FMs have different specializations and are able to produce a range of outputs based on prompts with high levels of accuracy.

Stability Diffusion Model by Stability.AI is good for image generation.
GPT-4 is used by ChatGPT for natural language.

You can adjust the inference parameters, weights, and other parameters specific to the FM and perform model evaluations to further refine the model to match your use-cases and organization needs.

to start working with the FMs, Log into your AWS Console UI, then navigate to the Amazon Bedrock page, then select the model access page from the bottom left of the page. then click on the specific models button and select the FMs you would like to use in your API or application.

Upon submitting the request, the selected models from the previous step will be available for you to use.

Note:
The model access you set on this page is region-specific.

You are now ready to leverage Amazon Bedrock Foundation Models. Start building and scripting your applications to seamlessly interact with Amazon Bedrock and unleash its full potential!

Good Luck!

Amazon Managed Service for Apache Flink

Asanka Boteju — Sun, 12 Jan 2025 06:58:58 +0000

Amazon Managed Service for Apache Flink is a framework for processing data streams for usecases such as responsive analytics, ETL, and continued metric generation.

Amazon Managed Service for Apache Flink supports languages such as Java, SCALA, and SQL and Opens up access to many other aws service destinations such as S3, DynamoDB, Aurora, SNS, SQS, Redshift, Cloudwatch, etc.

AWS provides provisioned compute resources, parallel processing, automatic scaling, checkpoints, and snapshot application backups for you.

You can also combine AWS Lambda with Amazon Managed Service for Apache Flink to enable more robust usecases that need data aggregation, conversions to different formats, enriching, and encryption.

Amazon Kinesis for Near Realtime Streaming

Asanka Boteju — Sun, 12 Jan 2025 05:41:52 +0000

Amazon Kinesis Data Streams

Collect and store streaming data such as clickstream data, IoT, metrics, and logs in real time with Amazon Kinesis Data Streams.

✅AWS fully manages the infrastructure required to run Kinesis
✅Pay-as-you-go pricing model where you are billed based on your usage.
✅Write your own producer and consumer codes using KPL and KCL libraries.
✅Shards to improve throughput.
✅Optionally, enable output data format conversions to Parquet or ORC with the support of Glue Catalogs.
✅Support for dynamic partitions.
✅Supports custom transformations with the use of lambda functions

Streaming

Destination

Output

Massively Scalable Processing & Massively Parallel Processing

Asanka Boteju — Sat, 11 Jan 2025 02:27:44 +0000

Massively Scalable Processing

Real-time processing systems designed to efficiently process large volumes of data in a distributed, massively scalable manner are known as massively scalable processing. Cloud-native solutions and distributed computing frameworks such as Hadoop and Spark are examples of such systems.

Features of MSP

Horizontal scalability Increasing the number of nodes (machines) to spread processing and storage over several systems is known as horizontal scalability.

Parallelism Dividing work into manageable portions that are handled concurrently by several nodes.

Fault tolerance Systems can gracefully bounce back from node outages or hardware malfunctions.

Scalability Distributed data storage allows for scalability of data access by distributing data among several nodes.

Dynamic Resource Allocation Allocating resources automatically in response to demand and load is known as dynamic resource allocation.

Use Case
Making use of scalable processing frameworks for big data analytics, real-time data processing, and ETL pipelines.

Massively Parallel Processing

Systems that are performing massively parallel large-scale processing utilizing multiple processors are known as massively parallel processing.
This approach is widely used in big data and analytics to handle massive datasets.

Features of MPP

Parallelism Several processors work on various aspects of a task at the same time.

Data partitioning Data partitioning is the process of dividing data into portions that are dispersed among nodes and handled separately.

Architecture of Shared Nothing
Every node has its own independent storage, memory, and CPU. Therefore, there is no resource contention, and it improves the scalability and fault tolerance.

Query parallelism SQL queries are divided and run concurrently on several nodes.

Data Locality To reduce data travel, computations are carried out on the nodes where the data is stored.

Use Case:
MPP architectures are used by database systems like Teradata, Snowflake, and Amazon Redshift to parallelize and spread queries across several nodes, allowing for quick query execution on large datasets.

Types of Data Analytics by its Application and Distinct Purposes

Asanka Boteju — Sun, 15 Dec 2024 16:36:10 +0000

Data analytics can be categorized into four main types based on its applications and distinct purposes.

1. Descriptive Analytics
The goal of descriptive analytics is to comprehend historical occurrences and turn data into insightful summaries. A retail business might, for instance, examine sales data to find that overall sales increased by 40% during the most recent quarter. Dashboards and reports are frequently created for this purpose using tools like Tableau or Power BI.

2. Diagnostic Analytics
By finding patterns and connections in data, diagnostic analytics seeks to determine the causes of particular outcomes. For instance, a bank may discover a correlation between increased unemployment in a region and an increase in loan defaults, in which the borrower fails to repay a loan according to the agreed terms.

3. Predictive Analytics
Predictive analytics forecasts future patterns by utilizing statistical models and past data. E-commerce companies, for instance, can use machine learning algorithms like regression or classification to forecast the purchasing habits of their customers.

4.Prescriptive Analytics
Prescriptive analytics takes one step further by integrating data with models and rules to recommend actions to get desired outcomes. For instance, a ride-sharing app may use demand projections and traffic patterns to suggest the best prices during peak hours.

Native Policy Enforcement Engine in Kubernetes

Asanka Boteju — Fri, 06 Dec 2024 18:14:33 +0000

This is about a policy engine that is native to Kubernetes and is used to develop, modify, and validate configurations for Kubernetes resources. Because policies are defined in YAML, this offers a declarative method of enforcing regulations without requiring developers to write code.

Key Features:

1. Types of Policies

Validation Policies: Verify that resources adhere to certain specifications (such as necessary annotations or labels).

Mutation Policies: Automatically change resources at runtime or during admission (e.g., inject default values, labels, or annotations).

Resources can be created or synchronized using generation policies (e.g., make sure a ConfigMap is always present).

2. Scope of Policy

Cluster Policy: applies to every namespace in the cluster.

Policy: Only applicable to one namespace.

3. Pattern Matching rules enable configurable requirements for matching Kubernetes

Resource fields using wildcard patterns ("" or "?") and JSONPath expressions.

4. Logs policy validation failure action audit

Audit: Records policy infractions but does not prevent the development of resources.

Enforce: Prevents the generation of resources in events that the policy is broken.

5. Management of Policies

Supports conditional reasoning, such as rules that match and exclude.

Certain namespaces, kinds, or labels may be the focus of policies.

permits the integration of several regulations into a single policy.

6. Contextual Dynamic

Adds other data sources (such as API calls or Kubernetes ConfigMaps) to make policies more context-aware and dynamic.

7. Usability

Policies, like Kubernetes manifests, are written in the well-known YAML format.

No need to pick up a sophisticated DSL or a new programming language.

8. Policy Reports: produces reports for implemented policies that display the state of compliance, audit findings, and infractions.

9. Integration of Webhooks

Functions as a real-time resource request interceptor for Kubernetes admission controller.

10. Isolation of Namespaces

In multi-tenant clusters, policies can be scoped to namespaces to isolate tenants.

11. The CLI Tool

Policies can be tested locally before being applied to a cluster using the CLI.

12. Personalized Materials

defines policies using Kubernetes CRDs (ClusterPolicy and Policy).

Use Case Examples:

Ensuring that resources have the necessary labels.

Adding default values to container limits and resource requests.
Ensuring security measures, such as limiting privileged containers or host networking.
ConfigMaps synchronization between namespaces.

This tool makes Kubernetes policy management easier for developers and operators by utilizing YAML and well-known Kubernetes concepts.

How it works

I hope this article was useful. Thank you!

Amazon S3 Tables: A Game Changer in Analytics and Data Lake Space

Asanka Boteju — Fri, 06 Dec 2024 17:59:12 +0000

Simplified data management and optimized query performance for workloads at any scale and as and when data grows.

What it offers:
1. Scalability.
2. Enhanced Performance.
3. Fully managed service.
4. seamless integration.
5. Simplified Security.

Historically, businesses and consumers have utilized Amazon S3 as a data lake to store enormous volumes of data workloads, which fueled analytics, machine learning workloads, and innovation across industries. However, securing and managing the data as it scales efficiently was challenging and required building complicated systems, which became a costly operation.

Amazon S3 tables, a new type of S3 bucket that is purpose-built to store tabular data and to lower cost for data at scale, make it easy to create and secure managed tables with just a few simple steps. You can define and manage access control policies and enforce security directly at the storage level.

Goodbye! to the maintenance complexity, governance, and lower query performance-related issues that you had to deal with manually. The new S3 Tables feature provides native support for Apache Iceberg and minimizes the operational complexities associated with Iceberg.

With S3 Tables, you get 3x faster, optimized query performance than querying tabular data that is stored in S3 buckets. To reduce your operational burden, AWS manages data compaction, snapshot management, and partitioning for you. S3 Tables also provides seamless integration with Amazon Athena, AWS Glue, and EMR services.

Docker Images for Go (Golang) Small, Faster Docker Images and Security

Asanka Boteju — Sat, 03 Aug 2024 08:23:13 +0000

During the weekend I was doing some research on docker images specifically to be used with Go (Golang) applications. hence, thought of sharing the interesting findings as that might be useful to someone who's exploring the same for their tech project works.

Here, I will be elaborating a few different ways we can build an image for Golang and also highlight some of the security considerations that we need to take into account when picking one.

For this exercise I was using a simple Rest API developed using Go (Golang) using the Gin Framework.

The Gin framework is a popular web framework for Go (Golang) that is designed to be fast, easy to use, and highly efficient.

Here's a brief summary of its key features and characteristics;

Key Features

Performance: Gin is known for its high performance. It is one of the fastest Go web frameworks, providing a minimal overhead compared to other frameworks.
Fast HTTP Router: Gin uses a fast HTTP router and supports routing with methods like GET, POST, PUT, DELETE, etc. It also supports middleware and route grouping.
Middleware Support: Gin provides a way to use middleware to handle tasks such as logging, authentication, and other pre- or post-processing of requests.
JSON Validation: The framework offers built-in support for JSON validation and binding request data to Go structs, making it easier to work with JSON payloads.
Error Handling: Gin has a structured way of handling errors and provides a central error management system, allowing you to handle errors gracefully.
Template Rendering: While Gin is primarily designed for API development, it supports HTML template rendering if needed.
Request Handling: Supports different methods for request handling including form data, JSON payloads, and URL parameters.
Built-in Debugging: Gin provides detailed error messages and debugging information that can be useful during development.

Key Components

Router: The core component that handles routing of HTTP requests to the appropriate handlers.
Context: A structure that carries the request and response data, and
provides methods to handle them. It's used extensively within handlers.
Engine: The primary instance of the Gin application, which is configured with routes, middleware, and other settings.
Middleware: Functions that execute during the request lifecycle, allowing you to perform tasks like logging, authentication, and more

Enough about Gin Framework :) now let's move into the main topic and talk about the Tests carried out.

Test 1 (Regular Docker Build)

In this Test we will be using a Official Standard/Regular Go Base Image

# Official Go Base Image
FROM golang:1.21.0

# Create The Application Working Directory
WORKDIR /app

# Copy and Download Dependencies
COPY go.mod go.sum .
RUN go mod download

# Copy Source and Build The Application
COPY . .
RUN go build -o main .

# Expose The Port
EXPOSE 8081
CMD ["./main"]

Image Size

Test 2 (Multi-Stage Docker Build with Alpine Image)

In this Test we will be use the Alpine version of the Go Base Image which is slightly more lightweight

# Official Go Apline Base Image
FROM golang:1.21.0-alpine as builder

# Create The Application Directory
WORKDIR /app

# Copy and Download Dependencies
COPY go.mod go.sum .
RUN go mod download

# Copy The Application Source & Build
COPY . .
RUN go build -o main .

# Final Image Creation Stage
FROM alpine:3.19

WORKDIR /root/

# Copy The Built Binary
COPY --from=builder /app/main .

# Expose the port
EXPOSE 8081
CMD ["./main"]

Image Size

Here you can see that with a multi-staged build the image sizes are significantly reduced.

Test 3 (Distroless Build)

In this Test we will be using a Googles Distroless Go Base Image. Distroless images are known for being lightweight and secure containing only the minimal files required. In this these debug shells and unnecessary packages removed. therefore, you sacrifice the flexibility of having a package manager and a shell.

# Build Stage
FROM golang:1.21.0 as builder

# Set The Application Directory
WORKDIR /app

# Copy and Download Dependencies
COPY go.mod go.sum .
RUN go mod download

# Copy The Application Source and Build the application
COPY . .
RUN CGO_ENABLED=0 go build -o main .

# Final Image Creation Stage
FROM gcr.io/distroless/static-debian12

# Copy the built binary
COPY --from=builder /app/main /
CMD ["/main"]

Image Size

CGO_ENABLED=0: This is an environment variable setting that disables CGO (C-Go). CGO is a feature of Go that allows Go packages to call C code. Setting CGO_ENABLED=0 ensures that the build does not depend on any C libraries, producing a fully static binary. This is useful for creating lightweight and portable Go binaries that can run on any system without requiring additional dependencies.

Putting it all together, RUN CGO_ENABLED=0 go build -o main . means that Docker will execute a command to build a Go application in the current directory, producing a static binary named main that does not depend on any C libraries.

Summary

Image Size

Even though the Distroless images are slightly bigger than the alpine images the security threat/vulnerability consideration might compel to choose Distroless!. Hence think about all these facts and pick the one that matches your requirements

Alpine with Multi-Stage Builds is a good choice if you need more control over the build process, and if compatibility issues with musl libc are not a concern. It provides flexibility and is smaller than many other base images, but still includes more components than Distroless images which can lead to potential security vulnerabilities/threats.

Google Distroless Images are ideal for maximizing security and minimizing the attack surface. They provide a very minimal runtime environment, which can be beneficial for production systems where security is a priority. However, you sacrifice the flexibility of having a package manager and a shell.

Recommendation:

Use Alpine if you need flexibility and control over the build environment, and if compatibility issues with musl libc are not a problem.

Use Google Distroless if security and minimizing the attack surface are your top priorities, and you can ensure that your application has all its dependencies bundled properly.

Hope this was interesting and thank you for your time!

AWS multi-region Serverless application variant.

Asanka Boteju — Thu, 06 Jun 2024 01:04:41 +0000

Multi-Region applications comes in very handy when you want to deal with users from different geographical locations, eliminating latency issue depending on distance from the place where your users accesses your application and also helps in maintaining High-Availability and DR (Disaster Recovery) situations without disrupting your users in case of a regions downtime from your cloud service provider.

Below is a brief summary of the services used for the below variant.

Rote53:
Amazon Route 53 is a scalable and highly available domain name system (DNS) web service designed to route end-user requests to internet applications by translating domain names into IP addresses. It also provides domain registration, DNS health checks, and integrates seamlessly with other AWS services.
API Gateway: AWS API Gateway is a fully managed service that enables developers to create, publish, secure, and monitor RESTful and WebSockets APIs at scale. It seamlessly integrates with AWS services like Lambda, provides robust security features, and scales automatically to handle varying traffic loads.
Lambda: AWS Lambda is a Serverless compute service that allows you to run code without provisioning or managing servers. You can execute code in response to events such as changes in data, shifts in system state, or user actions, and it automatically manages the compute resources required.
DynamoDB: Amazon DynamoDB is a fully managed NoSQL database service that provides fast and predictable performance with seamless scalability. It is designed to handle large amounts of structured data and enables developers to offload the administrative burdens of operating and scaling distributed databases.
Amazon Macie: Amazon Macie is a fully managed data security and data privacy service that uses machine learning and pattern matching to discover, monitor, and protect sensitive data stored in Amazon S3. It helps you identify and safeguard your personally identifiable information (PII) and intellectual property, providing visibility into how this data is accessed and moved across your organization.

Systems Manager Secret Manager: AWS Systems Manager Secrets Manager is a service designed to help you protect access to your applications, services, and IT resources without the upfront cost and complexity of managing your own hardware security module (HSM) or physical infrastructure. It allows you to securely store, manage, and retrieve credentials, API keys, and other secrets through a centralized and secure service, providing fine-grained access control and auditing capabilities.

CloudWatch: Amazon CloudWatch is a monitoring and management service designed for developers, system operators, site reliability engineers (SREs), and IT managers. It provides data and actionable insights to monitor applications, understand and respond to system-wide performance changes, optimize resource utilization, and get a unified view of operational health.

Thank you for your time.

Flow of Setting up Lambda function invocation via API Gateway to perform a DynamoDB read/write operation

Asanka Boteju — Sun, 26 May 2024 14:48:50 +0000

Typical Authenticated Lambda function invocation via API Gateway which will perform a DynamoDB read/write operation

Acquiring a token passing credentials.
Invoking the API Gateway endpoint passing the JWT token.
API Gateway validates the token.
Upon successful Auth token validation, API Gateway routes the request to the desired destination lambda function.
Retrieve any credentials stored.
Retrieve / Save the incoming payload to the database.

Amazon Macie to detect sensitive data from your S3 Buckets

Asanka Boteju — Sun, 26 May 2024 07:58:55 +0000

Leaking data or sensitive information exposure can lead to many insecurities to your organization including loss of business reputation and trust as well as long-term financially losses. Therefore, security is something we should seriously look at including applying security prevention, detection guardrails, monitoring, remediation and governance to stay on top of security of your businesses and its applications. To manage these sort of issues AWS provides a variety of security services that can be applied at different levels to safe-guard you and your customers business data while uplifting your businesses security posture.

Amazon Macie is a fully managed, ML & pattern matching service that helps with data security and data privacy concerns. Macie can provide a details list of sensitive information it can find in your S3 Buckets, so you can review them and take action. Actions can be done manually or by automating based on event using services like lambda and step functions. Automating prevent delays and human errors allowing you to act instantly to remediate or alerts on threats. Your content will be scanned based on pre-defined AWS defined rules as well as any rules you define by your own (custom rules). Macie has a native integration with AWS Organizations to allow centrally govern and perform scaled operations across your organization.

Machine can find PII (Personally Identifiable Information) such as Name, Address and contact details. National Information such as your Passports, Identities, Drivers License and Social Security Numbers), Medical Information such as Medical data, pharmacy information and even credentials and keys such as AWS Secret Keys and Private Keys etc.

That's not all, Macie can scan and detect threats related to PFI (Personal Financial Information) such as Credit Card Numbers and Bank Account Details also. Macie will scan and detect threats and present them in the form of findings via different AWS services such as Macie's Console, Macie's API's, Amazon EventBridge and Security Hub.

In order to scan and proceed with the threat detection within the data stored in your S3 Buckets, it uses a Service Linked Role to acquire necessary permission to create an inventory of all your s3 buckets, monitor, collect statistics, analyze the object and detect sensitive information. Macie also create metadata about all your S3 buckets, Usually these metadata gets refreshed every 24h as part of Macie's refresh cycle and you can also trigger it manually from the Macie's Console every 5 minutes. The metadata captures below will be use for on-going and future threat detection operations.

Macie will create a finding for each threats it detects from the moment you enabled Macie. For example, if someone disables the default encryption for a bucket, it will create a finding for you to review.

Some of the captured metadata includes

Name
ARN
Creation Date
Account-Level Access/Permissions
Shared/Cross-Account Access and Replication Settings
Object Counts etc.

During the scanning and threat detection activity Macie looks for Unencrypted buckets, Publicly accessible bucket and Buckets shared with other accounts without an explicit allowed defined and then analyze and collect findings for the below listed categories.

- S3BucketPublicAccessDisabled
- S3BucketEncryptionDisabled
- S3BucketPublic
- S3BucketReplicatedExternally
- S3BucketSharedExternally

With each finding will have a severity defined and general information about the threat including bucket name, when and how Macie was able detect the threat. These findings will be available for 90 days from the date the scan triggered and collected the information and can be viewed and explored from Macie's Console, Macie's APIs, EventBridge and AWS Security Hub to take necessary security precautions to mitigate the detected issues. You can also suppress findings, if you are sure that those are based on your comp policies and regulations that's in place.

Important to Note:
Your S3 Buckets could have different Server-Side/Client Side Encryptions configured and depending on the method configured for each Bucket or all the buckets as a whole, there are some implication that prevents Amazon Macie from analyzing and detecting threats from your S3 Buckets.

For instance, you could have used SSE-S3, SSE-KMS Server-Side Encryptions configured for your S3 Buckets, if that's the case then no issues Macie can scan, detect and report threats.

However, if you used CMK (Customer Managed Keys) for encrypting your S3 data then you have to explicitly allow Macie to use that key during the execution of the Sensitive Data discovery job which can be configured to run either one time, daily, weekly or monthly basis and collects findings, otherwise Macie will find it difficult to proceed with the Job of analyzing and detecting threats as it can not decrypt the data.

Similarly, for SSE-C (Server-side encryption with customer provided keys) Macie is unable to decrypt analyze and detect threats therefore Macie will just report metadata about your Buckets, same goes for any S3 Buckets configured to use Client-Side-Encryption.

Also note that Macie will not be able to Analyze and detect threats in Audio, Video, Image files for that you may have to use another service from AWS like Amazon Rekognition.

Further, It is key to keep in mind that an organization can only have a single administrator account at a given time. And an account cannot be both a Macie administrator as well as a member account.

However, If you ever wish to change the Macie administrator account then note that all member accounts will be removed. However, Macie will not be disabled from those member accounts.

A member account can only be associated with one administrator at a given time and it is unable to disassociate itself from that administrator once the member account is associated to the administrator account.

Thank you for your time...