Integrations are used to connect your Shippable CI or CD workflows to third party platforms or services and manage secrets that might be needed by your applications. They are owned by users of our platform and the scope feature allows you to decide which organizations/repos have access to use it in their DevOps activities.
One the biggest benefits of using Shippable DevOps Assembly Line Integrations as opposed to using encrypted strings that contain the connection information is "Separation of Concerns." These are the problems of using encrypted strings:
- The seed key used to encrypt is a single point of failure.
- Rotating the seed key means you have to change the encrypted strings wherever they are used.
- There is no way to know which key that was used to encrypt it purely look at the encrypted string. This means additional DB of what, when, which, and how the values were encrypted which is additional work.
- Scripts if they contain the encrypted values cannot participate in fork-based development. The reason for this is that unless every fork has access to the seed key, they will need to encrypt and replace these values. This means you will have to add it to
.gitignoreso that you don't override the parent's encrypted values. Changing these scripts through PRs is a pain.
- It is impossible to know which values are present in which encrypted strings, which means I have to decrypt to know what is present in the encrypted values.
- If any one of the values to change, unless you know where its used, there is no way to know which encrypted strings need to be updated
In case of Shippable Integrations,
- Internally Shippable is managing encryption at rest and flight which means the users are absolved from worrying about seed keys.
- Since the integration is used in scripts by reference pointers, changing the integration value in one place automatically propagates across every script that is using it. Maintenance of these integrations becomes trivial.
- Users of these integrations never need to know what the values are and since the integrations are well documented, they can correctly assume which keys they should use in their scripts.
- When these integrations are used in certain contexts, the platform automatically logs you in, or configures the CLI, which makes it easy for the script authors to interact with external entities.
- Removing access is as simple as removing the a repo from the scope and the immediate next run will start to fail.
- It is a more secure way of maintaining secrets.
We are big believers in the concept that secrets need to be separated from scripts for better security and privacy. All integrations are stored in our Vault store for maximum security.
Supported Orchestration Platform Integrations
- Amazon ECS
- Google Container Engine
- Azure Container Service
- Azure DC/OS
- Docker Cloud
- Docker Datacenter
- Joyent Triton
Supported Docker Registry Integrations
- AWS ECR
- Docker Hub
- Docker Trusted Registry
- Docker Private Registry
- Google Container Registry