SLA (Service Level Agreement) is a formal agreement between a service provider and client that defines the expected level of service. SLAs typically include service availability commitments and consequences for failing to meet them.

SLO (Service Level Objective) represents specific reliability targets that a team aims to achieve. For example, 99.9% availability means the service can be down for no more than 43.8 minutes per month.

SLI (Service Level Indicator) refers to actual metrics measuring service performance. Examples include request success rate or response time. SLIs show how well the service meets its stated SLOs.

Relationship between these metrics:

• SLA — Legal document with commitments
• SLO — Internal team goals (usually stricter than SLA)
• SLI — Actual service performance metrics

Examples:

SLA Example: “The service will be available 99.5% of the time, measured monthly. Failure to meet this commitment results in service credits.”

SLO Example: “Our internal target is 99.9% availability, with 99% of requests completing within 200ms.”

SLI Example: “Last month’s metrics: 99.95% uptime, average response time 150ms, 99.8% of requests successful.”

Common SLO Targets:

These metrics help teams:

• Set clear expectations with customers
• Monitor service health
• Make data-driven decisions about reliability improvements
• Balance reliability investments with other priorities

Whether it’s accessing your bank account, sending confidential emails, or deploying code to production servers, we need a way to ensure that:

• Only intended recipients can read the message (privacy)
• Messages haven’t been tampered with (integrity)
• We can verify who sent the message (authenticity)

Simply using random strings or UUIDs as secret keys for secure data exchange isn’t enough because:

• They can be intercepted and reused by attackers
• They don’t provide a way to verify the sender’s identity
• They don’t ensure message integrity

Key Terms

• Encryption: Process of converting readable data (plaintext) into scrambled form (ciphertext) using a key
• Decryption: Converting ciphertext back to plaintext using the corresponding key
• Signing: Creating a digital signature using your private key to prove you authored/approved something
• Verification: Checking a digital signature using the sender’s public key to confirm authenticity

Related reading: Hashing, Encoding, Encryption

Key Concepts

• Public Key: Shared openly, used for encryption and verification
• Private Key: Kept secret, used for decryption and signing
• Digital Certificate: Contains public key and identity information, signed by a trusted authority
• Certificate Authority (CA): Trusted entity that issues and signs digital certificates

Can we use private key for encryption and verification?
an we use public key for decryption and signing?

No! The roles of public and private keys cannot be reversed. Here’s why:

• Encryption and Verification: Only public keys can be used for these operations because they are designed to be shared and used by anyone
• Decryption and Signing: Only private keys can perform these operations because they must be kept secret and prove ownership/authority

This asymmetric relationship is what makes public key cryptography secure. If private keys could be used for encryption, anyone with access to the encrypted data would know which private key was used, compromising its secrecy.

Common use cases

1. SSH Authentication

• GitHub: SSH keys for repository access and deployment
• Server access: Secure remote login without passwords
• GitLab runners: Automated CI/CD pipeline authentication

How SSH Authentication Works

1. User generates SSH key pair locally
2. Public key is uploaded to remote system (GitHub/server/GitLab)
3. When connecting, user’s client proves ownership of private key
4. Remote system verifies proof using stored public key

What does “proves ownership” means?

The SSH authentication process using private key ownership works like this:

1. The client initiates connection to the server
2. Server sends a random challenge (a unique random string)
3. Client signs this challenge using their private key
4. Server verifies the signature using the stored public key

This process, called “challenge-response authentication”, proves the client has the private key without ever transmitting it. The server can be confident it’s talking to the legitimate user because only someone with the correct private key could produce a valid signature for the challenge.

2. Kubernetes

• TLS certificates for API server communication
• Client certificates for user authentication
• Service account tokens and certificates

Kubernetes Authentication Flow

1. Cluster admin generates certificates for components
2. Certificates are distributed to respective services
3. Components use certificates to establish secure connections
4. API server validates certificates during communication

Why just not to use private/public keys in k8s authentication flow?

While private/public key pairs alone could technically work for authentication, Kubernetes uses certificates (which include public keys) for several important reasons:

• Additional metadata: Certificates contain important information like user identity, roles, and expiration dates
• Built-in expiration: Certificates have validity periods, forcing regular key rotation
• Trust chain: Certificates can be signed by a trusted Certificate Authority, creating a verifiable chain of trust
• Standard format: X.509 certificates are widely supported and have standardized tools for management

These features make certificates more suitable for enterprise environments where security, compliance, and manageability are crucial.

3. Web Security

• SSL/TLS certificates for HTTPS websites
• Client certificates for mutual TLS authentication
• Code signing certificates

Web Security Flow

1. Website owner obtains certificate from Certificate Authority
2. Certificate (containing public key) is installed on web server
3. Browsers verify certificate using built-in CA certificates
4. Secure HTTPS connection is established using certificate

Let’s break down the Web Security Flow in more detail

1. Certificate Acquisition

Website owners obtain certificates from Certificate Authorities (CAs), which are trusted organizations that verify domain ownership and issue certificates. Popular CAs include:

• Let’s Encrypt (free, automated)
• DigiCert, Sectigo (commercial, with extended validation)

While you can create your own CA using OpenSSL (called a self-signed certificate), browsers won’t trust it by default. Self-signed certificates are typically used only in development or internal environments.

2. Certificate Installation

“Installing” a certificate involves:

• Copying certificate files (.crt/.key) to a secure location on the web server
• Configuring the web server (nginx/Apache) to use these certificate files
• Setting correct file permissions to protect private keys

3. Browser Trust Mechanism

Browsers maintain a list of trusted root certificates:

• Operating systems and browsers come with pre-installed root certificates from major CAs
• This list is regularly updated through OS/browser updates
• When visiting a website, the browser verifies its certificate was issued by one of these trusted CAs

Revised Web Security Flow

1. Website owner proves domain ownership to a Certificate Authority (CA)
2. CA verifies identity and issues a signed certificate
3. Website owner configures web server with certificate files:

• Secure storage of private key
• Configuration of web server software

4. When users visit the site:

• Browser receives server’s certificate
• Verifies it against built-in trusted CA certificates
• Establishes encrypted HTTPS connection if verification succeeds

Tools for Key Management

OpenSSL

Most versatile tool for certificate operations:

# Generate a private key
openssl genrsa -out private.key 2048

# Create a certificate signing request (CSR)
openssl req -new -key private.key -out request.csr

# Generate a self-signed certificate
openssl x509 -req -days 365 -in request.csr -key private.key -out certificate.crt

# View certificate contents
openssl x509 -in certificate.crt -text -noout

Let’s break down the OpenSSL commands:

• genrsa: Generates a new RSA private key with specified key length (2048 bits is the minimum recommended)
• req -new: Creates a certificate signing request (CSR) needed when requesting certificates from CAs
• x509 -req: Signs the CSR with your private key to generate a self-signed certificate valid for 365 days
• x509 -text: Displays certificate information in human-readable format

When running openssl req command, you’ll be prompted to enter various certificate details like Country, State, Organization, etc. For testing purposes, you can leave these fields empty by pressing Enter.

ssh-keygen

Primary tool for SSH key generation:

# Generate SSH key pair
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

# List generated SSH key files
ls -la ~/.ssh/

# Display public key content
cat ~/.ssh/id_rsa.pub

# View private key content (keep this secret!)
cat ~/.ssh/id_rsa

Let’s break down the ssh-keygen flags:

• -t rsa: Specifies the type of key to create. RSA is the most common algorithm, but you can also use others like ed25519, dsa, or ecdsa
• -b 4096: Sets the key length in bits. 4096 provides strong security (2048 is minimum recommended)
• -C "comment": Adds a comment to the key, typically your email address. This helps identify the key’s purpose or owner

Hashing

Hashing — the process of converting input data of any size into a unique fixed amount of bytes using a special algorithm.

Features:

• Collisions can occur, but the probability is usually very low.
• Each unique input data set gives a unique hash value (except in rare cases of collisions).
• Irreversible process, meaning the original data cannot be recovered from the hash.

Hashing Algorithms:

• SHA256, MD5, SHA1

In Python you can use hashlib library which supports SHA256, MD5, and SHA1 algorithms.

import hashlib

# Example data
data = "Hello, World!"

# SHA256
sha256_hash = hashlib.sha256(data.encode()).hexdigest()
print("SHA256:", sha256_hash)

# MD5
md5_hash = hashlib.md5(data.encode()).hexdigest()
print("MD5:", md5_hash)

# SHA1
sha1_hash = hashlib.sha1(data.encode()).hexdigest()
print("SHA1:", sha1_hash)

Output:

SHA256: dffd6021bb2bd5b0af676290809ec3a53191dd81c7f70a4b28688a362182986f
MD5: 65a8e27d8879283831b664bd8b7f0ad4
SHA1: 0a0a9f2a6772942557ab5355d76af442f8f65e01

Encoding

Encoding — the process of converting data into another format using a set of rules (or “codes”) so that the data can be easily recovered.

Features:

• Collisions do not occur; each unique input data set will always be converted into a unique output string.
• Reversible process, meaning the data can be easily decoded back into the original format after encoding.

Encoding Algorithms:

• Base64

In Python you can use base64 library which supports Base64 encoding and decoding.

import base64

# Example data
data = "Hello, World!"

# Encode
encoded_data = base64.b64encode(data.encode())
print("Encoded:", encoded_data)

# Decode
decoded_data = base64.b64decode(encoded_data).decode()
print("Decoded:", decoded_data)

Output:

Encoded: b'SGVsbG8sIFdvcmxkIQ=='
Decoded: Hello, World!

Encryption

Encryption — the process of converting data into another format to hide the original content and prevent unauthorized access.

Features:

• Each unique input data set will be converted into a unique output string after encryption.
• Reversible process, but the data can only be recovered using the corresponding encryption key.

Encryption Algorithms:

• AES, RSA, DES

In Python you can use cryptography library, which supports AES, RSA and DES algorithms.

from cryptography.fernet import Fernet

# Generate key
key = Fernet.generate_key()
cipher_suite = Fernet(key)

# Example data
data = "Hello, World!"

# Encrypt
cipher_text = cipher_suite.encrypt(data.encode())
print("Encrypted:", cipher_text)

# Decrypt
plain_text = cipher_suite.decrypt(cipher_text).decode()
print("Decrypted:", plain_text)

Output:

Encrypted: b'gAAAAABmpPPbnoBhSJbCdunYl1nPRyDXuhgoG3aLiAPbU7ZjRbQEt0BQJM5bepsgraBz97VYnuZF-uh_Xn6wPQLJE_Vpz260CQ=='
Decrypted: Hello, World!

1. FileResponse:

• Description: Designed for sending files that already exist on the disk.
• Usage: Convenient when you have a file that is already saved on the disk and you just want to send it to the client.
• Performance: In this case, the server does not need to load the entire file into memory. Instead, it reads the file from the disk and sends it to the client.
• Example:

return FileResponse(image_file, media_type="image/png", filename=image_file)

2. StreamingResponse:

• Description: Allows streaming data to the client.
• Usage: Suitable for scenarios where data is generated dynamically and/or can be large in size. Also useful for sending data that is not saved on the disk.
• Performance: Can be more efficient for transmitting large data as it allows sending data in chunks without loading the entire file into memory.
• Example:

return StreamingResponse(io.BytesIO(data.read()), media_type="image/png")

Behavior Differences:

• FileResponse reads the file from the disk and sends it to the client. It is convenient when the file already exists and does not require additional processing.
• StreamingResponse allows real-time data transmission, useful for cases where data is generated on-the-fly or can be large.

Which is Better?

• FileResponse is better suited for already existing files on the disk. It saves memory and simplifies the code.
• StreamingResponse is better suited for dynamically generated data or large files that are impractical to load entirely into memory before sending.