https://prefect.io logo
Join Slack
Powered by
<@ULVA73B9P> - Can you explain how i can use the "...
# ask-marvin
r
@Marvin - Can you explain how i can use the "PREFECT_CLIENT_CUSTOM_HEADERS" to help secure my self hosted prefect server?
m
✅ thought for 44.5 seconds
Based on the research, I need to be quite direct with you: while 
PREFECT_CLIENT_CUSTOM_HEADERS
exists as a configuration option, it's not primarily designed as a security feature for self-hosted Prefect servers. If your goal is to secure your self-hosted Prefect server, there are more robust and recommended approaches you should consider first. Here are the recommended security practices for a self-hosted Prefect server: 1. Basic Authentication - Enable basic authentication for your Prefect server - Set up API keys for client authentication - Configure through environment variables:
Copy code
bash
     PREFECT_SERVER_API_KEY_REQUIRED=true
     PREFECT_API_KEY=your-secure-api-key
2. TLS/HTTPS - Ensure your server uses TLS (minimum version 1.2) - Set up proper SSL certificates - Configure through a reverse proxy like nginx 3. Secure Storage - Use secure storage solutions for credentials (Kubernetes Secrets, HashiCorp Vault, etc.) - Implement proper environment variable management - Avoid storing sensitive information in plain text If you still specifically need to use 
PREFECT_CLIENT_CUSTOM_HEADERS
, it can be configured to add custom HTTP headers to requests made by the Prefect client to your server. However, this should be considered an additional layer rather than a primary security measure. You can set it like this:
Copy code
bash
PREFECT_CLIENT_CUSTOM_HEADERS='{"Custom-Auth-Header": "your-token", "Organization-ID": "your-org"}'
For proper security, I strongly recommend focusing on the core security features mentioned above. You can find more detailed information about Prefect security settings in the official documentation. Would you like me to elaborate on any of these security measures in more detail? Or do you have a specific use case for 
PREFECT_CLIENT_CUSTOM_HEADERS
that you'd like to discuss?
r
@Marvin - Using the custom headers (in addition to basic auth), how can it help ensure that no one unauthorized gets access to my prefect server, and that no unauthorized deployments can be created on my server (or general interactions with the API)
m
✅ thought for 116.7 seconds
Based on the research, I can explain how to implement a multi-layered security approach using custom headers alongside basic authentication to secure your Prefect server. Here's a comprehensive setup: 1. Basic Authentication Layer First, ensure basic authentication is enabled:
Copy code
bash
PREFECT_SERVER_API_KEY_REQUIRED=true
PREFECT_API_KEY=your-secure-api-key
2. Custom Headers Layer Add custom headers as an additional security check:
Copy code
bash
PREFECT_CLIENT_CUSTOM_HEADERS='{"X-Custom-Auth-Token": "your-secret-token", "X-Organization-ID": "your-org-id"}'
3. Nginx Reverse Proxy Configuration Configure your reverse proxy (e.g., Nginx) to validate these headers:
Copy code
nginx
server {
    listen 443 ssl;
    server_name <http://your-prefect-server.com|your-prefect-server.com>;

    # SSL configuration here...

    location / {
        # Deny if custom headers are missing or incorrect
        if ($http_x_custom_auth_token != "your-secret-token") {
            return 403;
        }
        if ($http_x_organization_id != "your-org-id") {
            return 403;
        }

        proxy_pass <http://your-prefect-server:4200;>
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        # ... other proxy settings
    }
}
4. Implementation Strategy To prevent unauthorized access and deployments: a) Server-side Validation: - Configure your reverse proxy to validate all custom headers before requests reach the Prefect server - Implement rate limiting and request validation - Enable CSRF protection b) Client-side Configuration: - All clients (workers, deployment creators) must have both:
Copy code
bash
  # Basic auth
  PREFECT_API_KEY=your-secure-api-key
  
  # Custom headers
  PREFECT_CLIENT_CUSTOM_HEADERS='{"X-Custom-Auth-Token": "your-secret-token", "X-Organization-ID": "your-org-id"}'
c) Secure Distribution of Credentials: - Store credentials in secure vaults (e.g., HashiCorp Vault, Kubernetes Secrets) - Use different tokens for different environments/teams - Regularly rotate tokens and API keys 5. Security Benefits This multi-layered approach provides: - Double Authentication: Requests must pass both basic auth and custom header validation - Request Origin Validation: Custom headers can help verify request sources - Granular Access Control: Different teams/environments can have different header values - Additional Attack Prevention: Headers can include timestamps or nonces to prevent replay attacks 6. Monitoring and Maintenance To maintain security: - Monitor failed authentication attempts in your logs - Regularly rotate all tokens and API keys - Audit access patterns periodically - Keep track of all clients with valid credentials 7. Important Considerations - Custom headers are transmitted with every request, so ensure they're always over HTTPS - Headers can be spoofed, which is why they should be used in combination with basic auth, not as the sole security measure - Consider implementing request signing for even more security - Monitor for any suspicious patterns in access logs Would you like me to elaborate on any of these aspects or provide more specific details about implementing any part of this security setup? Remember that while custom headers add an extra layer of security, they should be part of a comprehensive security strategy that includes proper network security, regular security audits, and following security best practices for your infrastructure as a whole.
r
@Marvin - How do i make sure my deployments gets this header? I am running my work in a google cloud run worker
m
✅ thought for 61.2 seconds
Based on the research, I'll provide a comprehensive guide on how to set up custom headers for your Google Cloud Run worker and ensure your deployments use them. Here's how to implement this: 1. Configure the Cloud Run Worker When deploying your worker to Cloud Run, you need to set the environment variables. You can do this in several ways: a) Using the Google Cloud Console: - Navigate to your Cloud Run service - Click "Edit & Deploy New Revision" - Under "Variables & Secrets" add:
Copy code
Name: PREFECT_CLIENT_CUSTOM_HEADERS
Value: {"X-Custom-Auth-Token": "your-secret-token", "X-Organization-ID": "your-org-id"}
b) Using gcloud CLI:
Copy code
bash
gcloud run deploy your-worker-service \
  --image your-worker-image \
  --set-env-vars "PREFECT_CLIENT_CUSTOM_HEADERS={'X-Custom-Auth-Token':'your-secret-token','X-Organization-ID':'your-org-id'}"
2. Configure Your Deployments For deployments to use the same headers when communicating with your Prefect server, you need to set the environment variables in your deployment configuration. Here's how: a) If using a deployment YAML file:
Copy code
yaml
deployments:
  - name: your-deployment
    flow_name: your-flow
    work_pool_name: your-work-pool
    work_queue_name: default
    tags: []
    schedule: null
    variables:
      env:
        PREFECT_CLIENT_CUSTOM_HEADERS: '{"X-Custom-Auth-Token":"your-secret-token","X-Organization-ID":"your-org-id"}'
b) If creating deployments programmatically:
Copy code
python
from prefect import flow
from prefect.deployments import Deployment

@flow
def your_flow():
    # your flow code here
    pass

deployment = Deployment.build_from_flow(
    flow=your_flow,
    name="your-deployment",
    work_pool_name="your-work-pool",
    variables={
        "env": {
            "PREFECT_CLIENT_CUSTOM_HEADERS": '{"X-Custom-Auth-Token":"your-secret-token","X-Organization-ID":"your-org-id"}'
        }
    }
)
deployment.apply()
3. Verify Configuration To verify your headers are being set correctly: a) Check your worker logs in Cloud Run to ensure the environment variable is present b) You can add a simple test in your flow:
Copy code
python
from prefect import flow
import os

@flow
def test_headers():
    headers = os.getenv("PREFECT_CLIENT_CUSTOM_HEADERS")
    print(f"Current headers: {headers}")
    return headers

if __name__ == "__main__":
    test_headers()
4. Security Best Practices When working with custom headers in Cloud Run: - Use Google Cloud Secret Manager to store sensitive header values - Reference secrets in your Cloud Run configuration:
Copy code
bash
gcloud run deploy your-worker-service \
  --image your-worker-image \
  --set-secrets "PREFECT_CLIENT_CUSTOM_HEADERS=custom-headers:latest"
- Regularly rotate your header values - Use different header values for different environments (dev/staging/prod) 5. Troubleshooting If your headers aren't working: - Verify the JSON formatting in your environment variable is correct - Check Cloud Run logs for any environment variable parsing errors - Ensure the headers match exactly what your server is expecting - Verify the environment variables are being passed correctly to your worker Would you like me to elaborate on any of these aspects or provide more specific details about any part of the configuration? Also, are you using any specific authentication method with your Cloud Run service that might need to be considered in this setup?
r
@Marvin Do i need to set it on both the worker and the deployments?
m
✅ thought for 26.5 seconds
Let me clarify this important point: You only need to set 
PREFECT_CLIENT_CUSTOM_HEADERS
on the worker, not on both the worker and deployments. Here's why: 1. Worker Role: - The worker is the component that actually makes API calls to your Prefect server - It handles all communication between your flows and the Prefect server - The worker needs the headers to authenticate its API calls 2. Deployment Role: - Deployments are metadata configurations that describe how to run your flow - They don't make API calls themselves - The worker uses the deployment configuration to execute the flow Therefore, in your Google Cloud Run setup: ✅ DO set on the worker:
Copy code
bash
# In your Cloud Run service configuration
PREFECT_CLIENT_CUSTOM_HEADERS='{"X-Custom-Auth-Token": "your-secret-token", "X-Organization-ID": "your-org-id"}'
❌ NOT needed in deployments: - You don't need to include the custom headers in your deployment configuration - The worker's headers will be used for all API calls This simplifies your setup and maintains better security by keeping the custom header configuration centralized at the worker level. The worker will use these headers for all API calls it makes on behalf of any deployment it processes. Would you like me to provide more details about how to verify the headers are working correctly on your Cloud Run worker?
r
@Marvin - So if someone un authorized manages to make a deployment passing the basic auth, it will actually have access as the worker holds the basic auth?
m
✅ thought for 65.1 seconds
Your question raises a critical security concern! Let me explain the security implications and how to properly secure your setup: 1. The Security Risk You've Identified Yes, you've spotted a potential security vulnerability. If you only rely on the worker's credentials (basic auth + custom headers), an attacker who manages to create a deployment could potentially: - Have their code executed by your authorized worker - Leverage the worker's credentials to access your Prefect server - Potentially access other resources the worker has access to 2. How to Properly Secure Your System To prevent unauthorized deployments from being executed, you need multiple layers of security: a) Server-Side Authentication
Copy code
bash
# On your Prefect server
PREFECT_SERVER_API_KEY_REQUIRED=true
b) Deployment Creation Security - Restrict who can create deployments using API keys:
Copy code
bash
# Required for deployment creation
PREFECT_API_KEY=your-deployment-creation-key
c) Worker Authentication
Copy code
bash
# On your Cloud Run worker
PREFECT_API_KEY=your-worker-key
PREFECT_CLIENT_CUSTOM_HEADERS='{"X-Custom-Auth-Token": "your-secret-token"}'
d) Work Pool Security
Copy code
bash
# Create a work pool with restricted access
prefect work-pool create "secure-pool" \
    --type cloud-run \
    --base-job-template '{"credentials": "encrypted-credentials"}' \
    --concurrency-limit 10
3. Implementation Best Practices a) Use Different API Keys: - One for deployment creation - Another for worker execution - Different keys for different environments b) Implement Work Pool ACLs:
Copy code
python
from prefect.client.cloud import get_cloud_client
from prefect.client.schemas.objects import WorkPool

client = get_cloud_client()
work_pool = client.read_work_pool("secure-pool")

# Set specific permissions
client.set_work_pool_access_policy(
    work_pool_name="secure-pool",
    access_policy={
        "allowed_users": ["<mailto:user1@company.com|user1@company.com>"],
        "allowed_teams": ["team-id-1"]
    }
)
c) Secure Your Cloud Run Service:
Copy code
bash
# Deploy with strict IAM policies
gcloud run deploy your-worker \
    --image your-image \
    --service-account <mailto:restricted-sa@project.iam.gserviceaccount.com|restricted-sa@project.iam.gserviceaccount.com> \
    --ingress internal \
    --no-allow-unauthenticated
4. Monitoring and Auditing Implement monitoring to detect suspicious activities: - Log all deployment creation attempts - Monitor worker execution patterns - Set up alerts for unusual activities Example monitoring setup:
Copy code
python
from prefect import flow
from prefect.logging import get_run_logger

@flow
def secure_flow():
    logger = get_run_logger()
    <http://logger.info|logger.info>("Flow execution started")
    # Add audit logging
    <http://logger.info|logger.info>(f"Execution context: {get_execution_context()}")
5. Regular Security Checks Implement a security routine: - Rotate API keys regularly - Audit work pool permissions - Review deployment configurations - Monitor Cloud Run service logs Would you like me to elaborate on any of these security measures or provide more specific implementation details for your setup? Also, are you using any specific Cloud Run security features that we should integrate into this security model? Remember: Security should be implemented in layers, and no single security measure (like custom headers or basic auth alone) should be relied upon exclusively.
r
@Marvin - is it possible to only set the env variable at the deployment level (i.e. the container to be executed by the worker)? In that way it will live on each deployment
m
✅ thought for 103.1 seconds
Yes, it's possible to set the custom headers at the deployment level instead of the worker level. This approach can indeed provide better isolation and security control. Here's how to implement it: 1. Using prefect.yaml
Copy code
yaml
deployments:
  - name: your-deployment
    version: null
    tags: []
    description: null
    schedule: null
    flow_name: your-flow
    entrypoint: flow.py:your_flow
    parameters: {}
    work_pool:
      name: your-work-pool
      work_queue_name: default
    variables:
      env:
        PREFECT_CLIENT_CUSTOM_HEADERS: '{"X-Custom-Auth-Token":"your-secret-token","X-Organization-ID":"your-org-id"}'
2. Using Python Deployment Configuration
Copy code
python
from prefect import flow
from prefect.deployments import Deployment

@flow
def your_flow():
    pass

deployment = Deployment.build_from_flow(
    flow=your_flow,
    name="your-deployment",
    work_pool_name="your-work-pool",
    variables={
        "env": {
            "PREFECT_CLIENT_CUSTOM_HEADERS": '{"X-Custom-Auth-Token":"your-secret-token","X-Organization-ID":"your-org-id"}'
        }
    }
)
deployment.apply()
3. For Cloud Run Specifically
Copy code
python
from prefect.deployments import Deployment
from prefect.infrastructure.container import Container

container_infrastructure = Container(
    env={
        "PREFECT_CLIENT_CUSTOM_HEADERS": '{"X-Custom-Auth-Token":"your-secret-token","X-Organization-ID":"your-org-id"}'
    },
    image="your-container-image:tag"
)

deployment = Deployment.build_from_flow(
    flow=your_flow,
    name="your-deployment",
    infrastructure=container_infrastructure,
    work_pool_name="your-cloud-run-pool"
)
Advantages of this Approach: 1. Isolation: Each deployment has its own headers 2. Granular Control: Different deployments can use different headers 3. Security Boundaries: Compromising one deployment doesn't compromise others 4. Easier Rotation: Can rotate credentials for specific deployments Security Considerations: 1. Secret Management:
Copy code
python
   # Use Prefect secrets for storing headers
   from prefect.blocks.system import Secret
   
   secret_block = Secret.load("custom-headers")
   headers = secret_block.get()
   
   deployment = Deployment.build_from_flow(
       flow=your_flow,
       variables={
           "env": {
               "PREFECT_CLIENT_CUSTOM_HEADERS": headers
           }
       }
   )
2. Environment-Specific Headers:
Copy code
python
# Different headers for different environments
headers = {
    "dev": {"X-Custom-Auth-Token": "dev-token"},
    "prod": {"X-Custom-Auth-Token": "prod-token"}
}

deployment = Deployment.build_from_flow(
    flow=your_flow,
    variables={
        "env": {
            "PREFECT_CLIENT_CUSTOM_HEADERS": headers[current_env]
        }
    }
)
Best Practices: 1. Use Secret Management: - Store headers in secret management systems - Use environment-specific secrets - Rotate secrets regularly 2. Audit and Monitoring:
Copy code
python
@flow
def audited_flow():
    from prefect import get_run_logger
    logger = get_run_logger()
    
    # Log (securely) when headers are used
    <http://logger.info|logger.info>("Flow execution with custom headers initiated")
    # Your flow logic here
3. Version Control: - Keep deployment configurations in version control - Use different header values for different branches/environments - Document header usage and rotation procedures Would you like me to elaborate on any of these aspects or provide more specific examples for your use case? Also, are you using any specific secret management solution in your Cloud Run environment that we should incorporate into this setup?
r
@Marvin - Using this approach (setting the variables at deployment level), can i have it read the token at runtime - such that i can keep the tokens in a secret manager
m
✅ thought for 47.4 seconds
Let me show you how to implement this with Google Cloud Secret Manager. Here's a complete solution: 1. First, install required packages:
Copy code
bash
pip install prefect-gcp[secret-manager]
2. Create a GCP Credentials Block:
Copy code
python
from prefect_gcp import GcpCredentials

# Create this once and reference it in your flows
gcp_creds = GcpCredentials(
    service_account_info={}  # Leave empty to use default credentials
).save("gcp-creds", overwrite=True)
3. Create a Flow that Sets Headers at Runtime:
Copy code
python
from prefect import flow, task
from prefect_gcp import GcpCredentials
import json
import os

@task
def get_custom_headers():
    # Load GCP credentials
    gcp_creds = GcpCredentials.load("gcp-creds")
    
    # Get secret from Secret Manager
    secret_value = gcp_creds.get_secret(
        secret_name="custom-headers",
        project="your-project-id"
    )
    
    # Parse the secret value (assuming it's stored as JSON)
    headers = json.loads(secret_value)
    
    # Set the environment variable
    os.environ["PREFECT_CLIENT_CUSTOM_HEADERS"] = json.dumps(headers)
    
    return headers

@flow
def your_flow():
    # This will set the headers at the start of the flow
    headers = get_custom_headers()
    
    # Your flow logic here
    print(f"Using custom headers: {headers}")
4. Create the Deployment:
Copy code
python
from prefect.deployments import Deployment

deployment = Deployment.build_from_flow(
    flow=your_flow,
    name="secure-deployment",
    work_pool_name="your-cloud-run-pool",
    variables={
        "env": {
            # These environment variables will be available to the container
            "GOOGLE_CLOUD_PROJECT": "your-project-id",
            # Add any other needed environment variables
        }
    }
)
deployment.apply()
5. Store Your Headers in Secret Manager:
Copy code
python
from prefect_gcp import GcpCredentials

# Example of storing headers in Secret Manager
headers = {
    "X-Custom-Auth-Token": "your-secret-token",
    "X-Organization-ID": "your-org-id"
}

gcp_creds = GcpCredentials.load("gcp-creds")
gcp_creds.create_secret(
    secret_name="custom-headers",
    secret_value=json.dumps(headers),
    project="your-project-id"
)
6. For Better Security, Use a Task to Manage Headers:
Copy code
python
from prefect import flow, task
from prefect_gcp import GcpCredentials
from contextlib import contextmanager
import json
import os

@contextmanager
def temporary_headers():
    """Context manager to handle header cleanup"""
    try:
        headers = get_custom_headers()
        yield headers
    finally:
        # Clean up the environment variable after use
        if "PREFECT_CLIENT_CUSTOM_HEADERS" in os.environ:
            del os.environ["PREFECT_CLIENT_CUSTOM_HEADERS"]

@flow
def secure_flow():
    with temporary_headers() as headers:
        # Your flow logic here
        print(f"Using custom headers: {headers}")
        # Headers will be automatically cleaned up after this block
7. For Production Use, Add Error Handling:
Copy code
python
from prefect import flow, task
from prefect.logging import get_run_logger
from prefect_gcp.exceptions import GcpError

@task(retries=3, retry_delay_seconds=60)
def get_custom_headers():
    logger = get_run_logger()
    try:
        gcp_creds = GcpCredentials.load("gcp-creds")
        secret_value = gcp_creds.get_secret(
            secret_name="custom-headers",
            project="your-project-id"
        )
        headers = json.loads(secret_value)
        os.environ["PREFECT_CLIENT_CUSTOM_HEADERS"] = json.dumps(headers)
        return headers
    except GcpError as e:
        logger.error(f"Failed to retrieve headers from Secret Manager: {e}")
        raise
    except json.JSONDecodeError as e:
        logger.error(f"Invalid header format in secret: {e}")
        raise
This approach provides several benefits: 1. Headers are only read when needed 2. Secrets are managed securely in Google Cloud Secret Manager
3. Headers can be rotated without redeploying 4. Access to headers can be audited through Secret Manager logs 5. Headers are cleaned up after use Would you like me to elaborate on any part of this implementation or provide additional examples for specific scenarios?
r
@Marvin What if i want to use the .yaml configuration instead of doing it at runtime?
m
✅ thought for 46.0 seconds
Yes, you can configure this in your 
prefect.yaml
file. Here's how to set it up to use Google Cloud Secret Manager: 1. First, create your 
prefect.yaml
:
Copy code
yaml
# prefect.yaml
deployments:
  - name: your-deployment
    version: null
    tags: []
    description: "Deployment with secure headers from Secret Manager"
    entrypoint: flow.py:your_flow
    parameters: {}
    work_pool:
      name: your-cloud-run-pool
      work_queue_name: default
    variables:
      env:
        # Reference to Secret Manager
        PREFECT_CLIENT_CUSTOM_HEADERS: '{{ prefect.blocks.secret_manager.gcp-secret-manager.get_secret("custom-headers") }}'
        # Add any other needed environment variables
        GOOGLE_CLOUD_PROJECT: "your-project-id"
2. Set up the GCP Secret Manager Block Create a file called `create_blocks.py`:
Copy code
python
from prefect_gcp import GcpCredentials
from prefect_gcp.secret_manager import SecretManagerBlock

# Create and save GCP credentials block
credentials = GcpCredentials(
    service_account_info={},  # Leave empty to use default credentials
    project="your-project-id"
)
credentials.save("gcp-credentials", overwrite=True)

# Create and save Secret Manager block
secret_manager = SecretManagerBlock(
    gcp_credentials=credentials,
)
secret_manager.save("gcp-secret-manager", overwrite=True)
3. Store your headers in Secret Manager:
Copy code
python
from prefect_gcp import GcpCredentials
import json

headers = {
    "X-Custom-Auth-Token": "your-secret-token",
    "X-Organization-ID": "your-org-id"
}

gcp_creds = GcpCredentials.load("gcp-credentials")
gcp_creds.create_secret(
    secret_name="custom-headers",
    secret_value=json.dumps(headers),
    project="your-project-id"
)
4. Create your flow file (
flow.py
):
Copy code
python
from prefect import flow

@flow
def your_flow():
    # Your flow logic here
    print("Flow running with secure headers")

if __name__ == "__main__":
    your_flow()
5. Deploy your flow:
Copy code
bash
prefect deploy
6. Alternative YAML Configuration If you want to use a different secret for different environments, you can use YAML anchors and aliases:
Copy code
yaml
# prefect.yaml
variables: &base-variables
  env:
    GOOGLE_CLOUD_PROJECT: "your-project-id"

deployments:
  - name: dev-deployment
    entrypoint: flow.py:your_flow
    work_pool:
      name: dev-pool
    variables:
      <<: *base-variables
      env:
        PREFECT_CLIENT_CUSTOM_HEADERS: '{{ prefect.blocks.secret_manager.gcp-secret-manager.get_secret("dev-custom-headers") }}'

  - name: prod-deployment
    entrypoint: flow.py:your_flow
    work_pool:
      name: prod-pool
    variables:
      <<: *base-variables
      env:
        PREFECT_CLIENT_CUSTOM_HEADERS: '{{ prefect.blocks.secret_manager.gcp-secret-manager.get_secret("prod-custom-headers") }}'
7. Using with Different Secret Types You can also use different types of secrets depending on your environment:
Copy code
yaml
# prefect.yaml
deployments:
  - name: your-deployment
    variables:
      env:
        # For development (using a Prefect Secret block)
        PREFECT_CLIENT_CUSTOM_HEADERS: '{{ prefect.blocks.secret.dev-headers.get() }}'
        
        # For production (using GCP Secret Manager)
        # PREFECT_CLIENT_CUSTOM_HEADERS: '{{ prefect.blocks.secret_manager.gcp-secret-manager.get_secret("prod-headers") }}'
8. Prerequisites:
Copy code
bash
# Install required packages
pip install prefect-gcp[secret-manager]

# Run your block creation script
python create_blocks.py
This approach offers several benefits: 1. Configuration is declarative and version-controlled 2. Secrets are managed externally in Google Cloud Secret Manager 3. Different environments can use different secrets 4. No runtime code needed to fetch secrets 5. Easy to update secrets without changing deployment configuration
Would you like me to elaborate on any part of this setup or provide additional examples for specific scenarios? For example, I can show you how to set up different secret configurations for different environments or how to handle secret rotation.
2 Views
Open in Slack
PreviousNext
Powered by