Add Satama index in Cloud Services

docs/accounts/how-to-add-service-access-for-project.md

@@ -3,7 +3,7 @@
 Access can be granted to the following services:
 
 * Supercomputers **Puhti** and **Mahti**
-* Cloud services **cPouta**, **Rahti** and **Pukki DBaaS**
+* Cloud services **cPouta**, **Rahti**, **Pukki DBaaS** and **Satama**
 * Storage services **Allas** and **IDA**
 * Sensitive data services **SD Services**
 

docs/cloud/index.md

@@ -29,3 +29,9 @@ If you need an environment to run a containerised software application that does
 Noppe is a hosted platform for teaching and research. It provides a technical environment for hosting e.g. Jupyter Notebook, RStudio Server and Apache Spark environments combined with user management.
 
 If you need a turnkey solution for listed environments, choose [Noppe](noppe/index.md).
+
+### Satama
+
+Satama is a cloud-native container image registry for CSC. It provides a secure and centralized place for users to push and pull container images, just like Docker Hub, but with added features such as role-based access control, vulnerability scanning, and image signing. 
+
+If you need an environment to manage your images, choose [Satama](satama/index.md)

docs/cloud/satama/audit_logs.md

@@ -0,0 +1,31 @@
+# Audit Logs
+
+Audit logs provide a record of all important activities performed in Satama. These logs help administrators track user actions and investigate security incidents.
+
+Audit logs typically record actions such as:
+* User login attempts
+* Image push or pull operations
+* Project creation or deletion
+* Permission changes
+* Configuration updates
+
+### Viewing Audit Logs
+
+* Log in to Satama Web UI.
+* Click on **Logs**
+
+You can also check project wise logs by:
+
+* Click on your project.
+* Open **Log** tab.
+
+![Audit logs](img/logs_audit.png)
+
+Here, you can see all logs. Admin can review these logs to monitor system usage and detect suspicious activity.
+
+Audit logs are important for:
+
+* Security monitoring
+* Compliance requirements
+* Troubleshooting issues
+* User activity tracking

docs/cloud/satama/best_practices.md

@@ -0,0 +1,70 @@
+# Best Practices
+
+Following these best practices will help you manage container images in Satama efficiently and securely.
+
+### Organize Repositories Clearly
+
+If you are a project admin, create repositories in a way that makes sense to your team. For example, repositories can be grouped by:
+
+* Application
+* Microservice
+* Environment (development, staging, production)
+
+A clear structure helps others quickly locate and reuse images.
+
+### Assign Appropriate User Permissions
+
+Project administrators should assign permissions carefully.
+
+Only users who need to push images should receive **Developer** access. Users who only need to pull images should remain **Guests**. Limiting push permissions helps prevent accidental overwrites or unauthorized image modifications.
+
+### Use Robot Accounts for Automation
+
+Try to use project-scoped robot accounts rather than using personal login. 
+Robot accounts provide several advantages:
+
+* Controlled access permissions
+* Easier credential rotation
+* Reduced risk of exposing personal accounts
+
+This approach improves security and simplifies automation workflows.
+
+### Use CLI Secrets for Authentication
+
+If you authenticate using a myCSC account, always use the CLI secret instead of the Web UI password when logging in through Docker or other command-line tools.
+
+Using CLI secrets ensures secure authentication and prevents issues caused by expired UI sessions.
+
+### Avoid Using the latest Tag
+
+Avoid relying on the latest tag for production images. The latest tag can be overwritten and may not always refer to the expected version of an image.
+
+Instead, use meaningful and consistent tags such as:
+
+* Version numbers (v1.2.0)
+* Release identifiers (release-2024-01)
+* Commit hashes (git-sha)
+
+Using explicit version tags improves traceability and ensures reproducible deployments.
+
+### Regularly Review Vulnerability Reports
+
+Periodically review vulnerability scan reports for images stored in Satama.
+
+If vulnerabilities are detected:
+* Update the base image
+* Update affected packages
+* Rebuild the container image
+
+High-severity vulnerabilities should be addressed before deploying images to production environments.
+
+### Remove Unused Images
+
+Over time, repositories may accumulate outdated images and unused tags. Removing these unused artifacts helps keep the registry organized.
+
+Cleaning up old images provides several benefits:
+* Reduces storage usage
+* Prevents confusion between image versions
+* Improves overall repository management
+
+Administrators can also configure tag retention policies to automatically remove outdated tags while preserving the most recent or important versions. 

docs/cloud/satama/billing_and_quota.md

@@ -0,0 +1,25 @@
+# Billing 
+
+## Terminology
+
+* Billing Unit (BU): A unit used for billing at CSC - each resource consumes a given amount of BUs per hour.
+
+* Storage Billing Unit: Billing Units assigned to usage of storage.
+
+* CSC Project: A placeholder for the user's resources information - including: the number of Cloud BUs and the CSC services which are available for use.
+
+* Satama Project: A Satama project is one which is created at https://satama.csc.fi after satama service is activated at CSC project.
+
+## Billing Model
+
+Currently, Satama will bill for storage only. Billing is based on the amount of data stored. The account of resource usage is provided in one-hour increments. The rate is 3 Storage BU/TiBh i.e. 1 Tib of data stored at Satama will consume 3 Storage BU per hour and 72 Storage BU in a day.
+
+If 10GB of storage is consumed, BU can be calculated using the following formula 
+```
+(10/1024) * 3 ~= 0.029 BUs per hour
+```
+A good way to estimate usage cost is the [Billing Unit calculator](https://research.csc.fi/resources/#buc) utility. For more information about Billing in CSC, visit the [Billing](../../accounts/billing.md) page.
+
+# Quota
+
+The default quota for a new project is **50 GB**, but this can be increased if needed. If you need more resources than the defaults, you can apply for more quota by contacting the Service Desk. See the [Contact page](../../support/contact.md) for instructions. Quota requests are handled on a case-by-case basis depending on the currently available resources in Satama and the use case.

docs/cloud/satama/cli.md

@@ -0,0 +1,95 @@
+# Command Line Tool
+
+Most day-to-day operations, such as pushing or pulling images, require you to authenticate with Satama using OCI compatible tools like, Docker and Podman. It's a good idea to use CLI secret instead of a password for security reasons. The CLI secret functions as a token that grants permission to interact with the registry via command line tools. 
+
+## Logging in to Satama Using Personal CLI Secret
+
+To generate your CLI secret, log in to the Satama web interface, click on your username in the upper right corner, and select **User Profile**. A pop-up window will be displayed.
+
+![Generate Token](img/generate_token.png)
+
+Within this page, you will see a section labeled **CLI Secret**. If you have not generated one before, click **Generate New Secret**, and Satama will display a unique string of characters. This secret should be copied and stored securely. It acts like a personal API key and can be revoked or regenerated at any time.
+
+!!! warning "Known Issue"
+
+    If you see errors such as “unauthorized” , your session token may have expired. In this case, log out from the Satama web UI and log in again. This will refresh the token, copy that and then authenticate again using Docker/Podman.
+
+You can log in from the terminal using this secret by running the following command:
+
+To log in using Docker:
+```
+docker login satama.csc.fi -u <your-username>
+```
+You will be prompted to enter your password. Add this CLI secret there. 
+```
+Password:
+```
+If the authentication is successful, the terminal will display:
+```
+Login Succeeded
+```
+
+The same process can be performed using Podman:
+```
+podman login satama.csc.fi -u <your-username>
+```
+
+Once you’ve logged in successfully, Docker/Podman will save your credentials locally, allowing you to perform push and pull operations without re-authenticating until your session expires or you log out manually.
+
+
+## Logging in to Satama Using Robot Account  
+
+It is recommended to use robot accounts instead of personal credentials to login specially when it is used in automated workflow. Robot accounts provide secure token-based authentication and can be limited to specific projects.
+
+To know more about robot account, read [robot account](robot_account.md) .
+
+Log in using robot account:
+```
+docker login satama.csc.fi -u <your-robot account> 
+```
+For example,
+```
+docker login satama.csc.fi -u robot@test-project+test
+```
+You will be prompted to enter your password. Add CLI secret of the robot account. If you don't have credentials, please ask your project admin.
+
+## Pulling an Image
+
+To use an existing container image stored in Satama, you can pull it using the CLI. Pulling an image downloads its layers and metadata to your local machine so that you can run containers from it. The basic syntax is:
+```
+docker pull satama.csc.fi/<project>/<repository>:<tag>
+```
+This command downloads the specified image and stores it locally so it can be executed or used as a base image for other builds.
+
+
+## Tagging an Image
+
+If you have built a new image locally and want to store it in Satama, you need to tag it correctly before pushing. Tagging an image tells Docker where to send it within the registry. Suppose you want to push a ubuntu:24.04 image. To push it to your project, you would tag it like this:
+```
+docker tag ubuntu:24.04 satama.csc.fi/<project>/ubuntu:24.04
+```
+This prepares the image to be uploaded to the project repository.
+
+You can also check available images on your system using:
+```
+docker images
+```
+
+## Pushing an Image
+
+Once an image is tagged correctly, it can be pushed to the registry, using:
+```
+docker push satama.csc.fi/<project>/ubuntu:24.04
+```
+You can check push command for your project on web UI by selecting your project and in right-hand side, clicking on **PUSH COMMAND**
+
+![Push Commands](img/push_commands.png)
+
+Docker will upload all the image layers to Satama. If it’s the first time pushing this image, all layers will be uploaded. Subsequent pushes of similar images will be faster since Docker reuses existing layers. When the push completes, you can verify that the image appears in the Satama web interface under the appropriate repository and tag. 
+
+Please note that if you encounter a “permission denied” error, it usually indicates that you don’t have push access to that project, and you should contact your project administrator.
+
+If an image is no longer needed locally, it can be removed to free disk space.
+```
+docker rmi IMAGE_NAME:TAG
+```

docs/cloud/satama/cve_allowlist.md

@@ -0,0 +1,16 @@
+# CVE Allowlist
+
+A CVE Allowlist is used to ignore specific vulnerabilities that are known but accepted temporarily.
+
+Sometimes vulnerabilities cannot be fixed immediately because:
+* No patch is available
+* The vulnerability is not exploitable in your environment
+* It does not affect the application functionality
+
+In these cases, administrators can add the vulnerability to the CVE Allowlist. This allows certain vulnerabilities to be ignored for this project. 
+
+You have two options: 
+* **System allowlist** Uses the global allowlist defined by Satama administrators 
+* **Project allowlist** uses defined custom CVEs specific to this project.
+
+You can click **ADD** to add CVE IDs manually. Click **COPY FROM SYSTEM** to copy global allowlist entries and set expiration date or choose "Never expires".

docs/cloud/satama/deployment_security.md

@@ -0,0 +1,15 @@
+# Deployment Security
+
+This section controls image verification and vulnerability enforcement.
+
+Administrators can enforce security policies such as:
+
+### Allowing only signed images
+
+Two image signature verification mechanisms are there, cosign and Notation. If enabled, only signed images can be deployed. It ensures image integrity and authenticity. 
+
+### Preventing the use of vulnerable images
+
+If 'Prevent vulnerable images from running' is enabled, Satama blocks deployment of images that contain vulnerabilities above a selected severity level. 
+
+You can adjust severity threshold from dropdown. If 'Low' vulnerability severity is selected, that means if any vulnerability (Low, Medium, High, Critical) exists, deployment can be blocked.

docs/cloud/satama/getting_access.md

@@ -0,0 +1,41 @@
+
+# Getting Access to Satama
+
+## Login Using a CSC Account
+
+In order to use the Satama container registry with a CSC account, you need:
+
+1. A CSC user account. You can check which is your "CSC username" in [MyCSC profile page](https://my.csc.fi/profile). You can also change the password from there. If you don't have a CSC account already, you can create one by following [Create a new CSC user account](../../accounts/how-to-create-new-user-account.md)
+
+2. Multi Factor Authentication (MFA) is required when login. For more information, visit the [Multi-Factor Authentication (MFA) Guide](../../accounts/mfa.md)
+
+3. A CSC project with Satama service enabled. To create a new CSC project, follow [Create a new CSC project](../../accounts/how-to-create-new-project.md) or ask to be added to an existing project. The project should have Satama service enabled to access. Follow [Apply for Satama access](../../accounts/how-to-add-service-access-for-project.md) to enable Satama in your CSC project.
+
+Please contact [servicedesk@csc.fi](mailto:servicedesk@csc.fi) in case you need assistance.
+
+## Change Role of Individual Members
+
+The user must be added to the MyCSC project and then log in to the Satama platform. This will automatically create a username on Satama. When a user logs in for the first time, only **library** project will be visible. After 15 minutes, other CSC projects with Satama enabled will appear.
+
+By default, everyone having access to project have **Project admin** role. Members with project admin role, can remove members and change the role of other members in the project. However, please note that these changes are temporary and may be overridden by the periodic synchronization process. Satama enforces role-based access control to ensure that only authorized users can perform specific actions.
+
+1. Click on your project 
+2. Click on **Members** tab
+3. Select the member from the list
+4. Click on **Action..**
+5. A list will appear
+6. Remove/change role of that member.
+
+![Change Role](img/assign_role.png)
+
+The primary roles are Limited Guest, Guest, Developer, Maintainer, and Project Admin.
+
+* **Limited Guest** can pull images but cannot push, and they cannot see logs or the other members of a project.
+* **Guest** has read-only permission, they can only retag and pull images.
+* **Developer** can both push and pull images.
+* **Maintainer** have extended rights, such as the ability to scan images, view replications jobs, and delete images and helm charts.
+* **Project Admin** can manage project members, assign roles, configure project settings and starting a vulnerability scan.
+
+If you find that you cannot perform certain actions, such as pushing an image or initiating a scan, it’s likely due to insufficient permissions. In such cases, you should contact your project administrator to adjust your role or confirm your access level. You can check detail permission of the role [here](https://goharbor.io/docs/2.14.0/administration/managing-users/user-permissions-by-role/). 
+
+It is also possible to have read-only access to public projects when user is not logged in. That type of user is known as **Anonymous user**. 

docs/cloud/satama/index.md

@@ -0,0 +1,20 @@
+# Satama
+
+Welcome to the Satama container registry. This is CSC's own container registry designed to securely store, manage, and distribute container images within the organization.
+
+Satama provides more than just image storage. It includes additional features such as vulnerability scanning and SBOM (Software Bill of Materials) generation, helping users understand what is inside their images and identify potential security risks. These features support secure development, compliance requirements, and safer deployments.
+
+By using Satama, teams can ensure that container images are centrally managed, properly versioned, and accessible only to authorized users. This helps maintain reliability, security, and consistency across development, research, and production environments. 
+
+To understand more about Satama and how to use this, please read following topics:-   
+
+* [What is Satama?](what_is_satama.md)
+* [Getting Access](getting_access.md)
+* [Web User Interface](ui.md)
+* [Command Line Tool](cli.md)
+* [Billing and Quota](billing_and_quota.md)
+* [Project Configuration](project_configuration.md)
+* [Known Issues](known_issues.md)
+* [Best Practices](best_practices.md)
+* [Tutorials](tutorials/index.md)
+* [FAQ](../../support/faq/index.md#satama)