-
-
Notifications
You must be signed in to change notification settings - Fork 26
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge remote-tracking branch 'origin/master' into feature/dev-123-upd…
…ate-release-engineering-documentation-to-suggest-design
- Loading branch information
Showing
55 changed files
with
2,497 additions
and
1,227 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,135 @@ | ||
| --- | ||
| title: "Deploy 1Password SCIM Bridge" | ||
| sidebar_label: "1Password SCIM Bridge" | ||
| description: "Deploy the 1Password SCIM Bridge for ECS environments" | ||
| --- | ||
|
|
||
| import Intro from "@site/src/components/Intro"; | ||
| import Steps from "@site/src/components/Steps"; | ||
| import Step from "@site/src/components/Step"; | ||
| import StepNumber from "@site/src/components/StepNumber"; | ||
| import CollapsibleText from "@site/src/components/CollapsibleText"; | ||
|
|
||
| <Intro> | ||
| The 1Password SCIM Bridge is a service that allows you to automate the management of users and groups in 1Password. This guide will walk you through deploying the SCIM Bridge for ECS environments. | ||
| </Intro> | ||
|
|
||
| ## Implementation | ||
|
|
||
| The implementation of this is fairly simple. We will generate credentials for the SCIM bridge in 1Password, store them in AWS SSM Parameter Store, deploy the SCIM bridge ECS service, and then finally connect your chosen identity provider. | ||
|
|
||
| <Steps> | ||
| <Step> | ||
| ### <StepNumber/> Generate Credentials for your SCIM bridge in 1Password | ||
|
|
||
| The first step is to generate credentials for your SCIM bridge in 1Password. We will pass these credentials to Terraform and the ECS task definition to create the SCIM bridge. | ||
|
|
||
| <Steps> | ||
| 1. Log in to your 1Password account | ||
| 1. Click Integrations in the sidebar | ||
| 1. Select "Set up user provisioning" | ||
| 1. Choose "Custom" | ||
| 1. You should now see the SCIM bridge credentials. We will need the "scimsession" and "Bearer Token" for the next steps. | ||
| 1. Save these credentials in a secure location (such as 1Password) for future reference | ||
| 1. Store only the "scimsession" in AWS SSM Parameter Store. This will allow the ECS task definition to access the credentials securely. Then once the service is running, the server will ask for the bearer token to verify the connection, which we will enter at that time. | ||
|
|
||
| <Steps> | ||
| - Open the AWS Web Console - Navigate to the target account, such as `core-auto`, and target region, such as `us-west-2` | ||
| - Open "AWS System Manager" > "Parameter Store" | ||
| - Create a new Secure String parameter using the credentials you generated in the previous step: `/1password/scim/scimsession` | ||
| </Steps> | ||
| </Steps> | ||
|
|
||
| There will be additional steps to complete the integration in 1Password, but first we need to deploy the SCIM bridge service. | ||
| </Step> | ||
|
|
||
| <Step> | ||
| ### <StepNumber /> Deploy the SCIM bridge ECS Service | ||
|
|
||
| The next step is to deploy the SCIM bridge ECS service. We will use Terraform to create the necessary resources with our existing `ecs-service` component. Ensure you have the `ecs-service` component and `ecs` cluster before proceeding. | ||
|
|
||
| If you do not have ECS prerequisites, please see the [ECS layer](/layers/ecs) to create the necessary resources. | ||
|
|
||
| <Steps> | ||
| 1. Create a new stack configuration for the SCIM bridge. The placement of this file will depend on your project structure. For example, you could create a new file such as `stacks/catalog/ecs-services/1password-scim-bridge.yaml` with the following content: | ||
|
|
||
| <CollapsibleText type="medium"> | ||
| ```yaml | ||
| import: | ||
| - catalog/terraform/services/defaults | ||
|
|
||
| components: | ||
| terraform: | ||
| 1pass-scim: | ||
| metadata: | ||
| component: ecs-service | ||
| inherits: | ||
| - ecs-service/defaults | ||
| vars: | ||
| enabled: true | ||
| name: 1pass-scim | ||
| containers: | ||
| service: | ||
| name: op_scim_bridge | ||
| image: 1password/scim:v2.9.5 | ||
| cpu: 128 | ||
| memory: 512 | ||
| essential: true | ||
| dependsOn: | ||
| - containerName: redis | ||
| condition: START | ||
| port_mappings: | ||
| - containerPort: 3002 | ||
| hostPort: 3002 | ||
| protocol: tcp | ||
| map_environment: | ||
| OP_REDIS_URL: redis://localhost:6379 | ||
| OP_TLS_DOMAIN: "" | ||
| OP_CONFIRMATION_INTERVAL: "300" | ||
| map_secrets: | ||
| OP_SESSION: "1password/scim/scimsession" | ||
| log_configuration: | ||
| logDriver: awslogs | ||
| options: {} | ||
| redis: | ||
| name: redis | ||
| image: redis:latest | ||
| cpu: 128 | ||
| memory: 512 | ||
| essential: true | ||
| restart: always | ||
| port_mappings: | ||
| - containerPort: 6379 | ||
| hostPort: 6379 | ||
| protocol: tcp | ||
| map_environment: | ||
| REDIS_ARGS: "--maxmemory 256mb --maxmemory-policy volatile-lru" | ||
| log_configuration: | ||
| logDriver: awslogs | ||
| options: {} | ||
| ``` | ||
| </CollapsibleText> | ||
| 2. Confirm the `map_secrets` value for `OP_SESSION` matches the AWS SSM Parameter Store path you created previously, an confirm they are in the same account and region as this ECS service component. | ||
| 3. Deploy the ECS service with Atmos: | ||
| ```bash | ||
| atmos terraform apply 1pass-scim -s core-usw2-auto | ||
| ``` | ||
| </Steps> | ||
| </Step> | ||
|
|
||
| <Step> | ||
| ### <StepNumber/> Validate the Integration | ||
|
|
||
| After deploying the SCIM bridge ECS service, verify the service is running and accessible. Connect to the VPN (if deployed the ECS service is deployed with a private ALB), navigate to the SCIM bridge URL, and confirm the service is running. | ||
|
|
||
| For example, go to `https://1pass-scim.platform.usw1.auto.core.acme-svc.com/` | ||
| </Step> | ||
|
|
||
| <Step> | ||
| ### <StepNumber/> Connect your Identity Provider | ||
|
|
||
| Finally, connect your identity provider to the SCIM bridge. The SCIM bridge URL will be the URL you validated in the previous step. Follow the instructions in the 1Password SCIM Bridge documentation to connect your identity provider, using the Bearer Token you generated in the first step. | ||
|
|
||
| </Step> | ||
|
|
||
| </Steps> |
62 changes: 62 additions & 0 deletions
62
docs/layers/eks/design-decisions/decide-on-secrets-management-for-eks.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,62 @@ | ||
| --- | ||
| title: "Decide on Secrets Management for EKS" | ||
| sidebar_label: "Secrets Management for EKS" | ||
| description: Decide on the secrets management strategy for EKS. | ||
| --- | ||
| import Intro from '@site/src/components/Intro'; | ||
| import KeyPoints from '@site/src/components/KeyPoints'; | ||
|
|
||
| <Intro> | ||
| We need to decide on a secrets management strategy for EKS. We prefer storing secrets externally, like in AWS SSM Parameter Store, to keep clusters more disposable. If we decide on this, we'll need a way to pull these secrets into Kubernetes. | ||
| </Intro> | ||
|
|
||
| ## Problem | ||
|
|
||
| We aim to design our Kubernetes clusters to be disposable and ephemeral, treating them like cattle rather than pets. This influences how we manage secrets. Ideally, Kubernetes should not be the sole source of truth for secrets, though we still want to leverage Kubernetes’ native `Secret` resource. If the cluster experiences a failure, storing secrets exclusively within Kubernetes risks losing access to them. Additionally, keeping secrets only in Kubernetes limits integration with other services. | ||
|
|
||
| To address this, several solutions allow secrets to be stored externally (as the source of truth) while still utilizing Kubernetes' `Secret` resources. These solutions, including some open-source tools and recent offerings from Amazon, enhance resilience and interoperability. Any approach must respect IAM permissions and ensure secure secret management for applications running on EKS. We have several options to consider that balance external secret storage with Kubernetes-native functionality. | ||
|
|
||
| ### Option 1: External Secrets Operator | ||
|
|
||
| Use [External Secrets Operator](https://external-secrets.io/latest/) with AWS SSM Parameter Store. | ||
|
|
||
| External Secrets Operator is a Kubernetes operator that manages and stores sensitive information in external secret management systems like AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, HashiCorp Vault, and more. It allows you to use these external secret management systems to securely add secrets in your Kubernetes cluster. | ||
|
|
||
| Cloud Posse historically recommends using External Secrets Operator with AWS SSM Parameter Store and has existing Terraform modules to support this solution. See the [eks/external-secrets-operator](/components/library/aws/eks/external-secrets-operator/) component. | ||
|
|
||
| ### Option 2: AWS Secrets Manager secrets with Kubernetes Secrets Store CSI Driver | ||
|
|
||
| Use [AWS Secrets and Configuration Provider (ASCP) for the Kubernetes Secrets Store CSI Driver](https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating_csi_driver.html). This option allows you to use AWS Secrets Manager secrets as Kubernetes secrets that can be accessed by Pods as environment variables or files mounted in the pods. The ASCP also works with [Parameter Store parameters](https://docs.aws.amazon.com/systems-manager/latest/userguide/integrating_csi_driver.html) | ||
|
|
||
| However, Cloud Posse does not have existing Terraform modules for this solution. We would need to build this support. | ||
|
|
||
| ### Option 3: SOPS Operator | ||
|
|
||
| Use [SOPS Operator](https://github.com/isindir/sops-secrets-operator) to manage secrets in Kubernetes. SOPS Operator is a Kubernetes operator that builds on the `sops` project by Mozilla to encrypt the sensitive portions of a `Secrets` manifest into a `SopsSecret` resource, and then decrypt and provision `Secrets` in the Kubernetes cluster. | ||
|
|
||
| 1. **Mozilla SOPS Encryption**: Mozilla SOPS (Secrets OPerationS) is a tool that encrypts Kubernetes secret manifests, allowing them to be stored securely in Git repositories. SOPS supports encryption using a variety of key management services. Most importantly, it supports AWS KMS which enables IAM capabilities for native integration with AWS. | ||
|
|
||
| 2. **GitOps-Compatible Secret Management**: In a GitOps setup, storing plain-text secrets in Git poses security risks. Using SOPS, we can encrypt sensitive data in Kubernetes secret manifests while keeping the rest of the manifest in clear text. This allows us to store encrypted secrets in Git, track changes with diffs, and maintain security while benefiting from GitOps practices like version control, auditability, and CI/CD pipelines. | ||
|
|
||
| 3. **AWS KMS Integration**: SOPS uses AWS KMS to encrypt secrets with customer-managed keys (CMKs), ensuring only authorized users—based on IAM policies—can decrypt them. The encrypted secret manifests can be safely committed to Git, with AWS securely managing the keys. Since it's IAM-based, it integrates seamlessly with STS tokens, allowing secrets to be decrypted inside the cluster without hardcoded credentials. | ||
|
|
||
| 4. **Kubernetes Operator**: The [SOPS Secrets Operator](https://github.com/isindir/sops-secrets-operator) automates the decryption and management of Kubernetes secrets. It monitors a `SopsSecret` resource containing encrypted secrets. When a change is detected, the operator decrypts the secrets using AWS KMS and generates a native Kubernetes `Secret`, making them available to applications in the cluster. AWS KMS uses envelope encryption to manage the encryption keys, ensuring that secrets remain securely encrypted at rest. | ||
|
|
||
| 5. **Improved Disaster Recovery and Security**: By storing the source of truth for secrets outside of Kubernetes (e.g., in Git), this setup enhances disaster recovery, ensuring secrets remain accessible even if the cluster is compromised or destroyed. While secrets are duplicated across multiple locations, security is maintained by using IAM for encryption and decryption outside Kubernetes, and Kubernetes' native Role-Based Access Control (RBAC) model for managing access within the cluster. This ensures that only authorized entities, both external and internal to Kubernetes, can access the secrets. | ||
|
|
||
| The SOPS Operator combines the strengths of Mozilla SOPS and AWS KMS, allowing you to: | ||
| - Encrypt secrets using KMS keys. | ||
| - Store encrypted secrets in Git repositories. | ||
| - Automatically decrypt and manage secrets in Kubernetes using the SOPS Operator. | ||
|
|
||
| This solution is ideal for teams following GitOps principles, offering secure, external management of sensitive information while utilizing Kubernetes' secret management capabilities. However, the redeployment required for secret rotation can be heavy-handed, potentially leading to a period where services are still using outdated or invalid secrets. This could cause services to fail until the new secrets are fully rolled out. | ||
|
|
||
| ## Recommendation | ||
|
|
||
| We recommend using the External Secrets Operator with AWS SSM Parameter Store. This is a well-tested solution that we have used in the past. We have existing Terraform modules to support this solution. | ||
|
|
||
| However, we are in the process of evaluating the AWS Secrets Manager secrets with Kubernetes Secrets Store CSI Driver solution. This is the AWS supported option and may be a better long-term solution. We will build the required Terraform component to support this solution. | ||
|
|
||
| ## Consequences | ||
|
|
||
| We will develop the `eks/secrets-store-csi-driver` component using the [Secrets Store CSI Driver](https://secrets-store-csi-driver.sigs.k8s.io/getting-started/installation) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.