feat: move GitLab secrets to secrets manager (part 1) #223
Conversation
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
michalc
force-pushed
the
feat/move-gitlab-secrets-to-secrets-manager
branch
from
bfa7023 to
d49047d
Compare
michalc
changed the title
michalc
changed the title
michalc
force-pushed
the
feat/move-gitlab-secrets-to-secrets-manager
branch
3 times, most recently
from
4a43e7e to
a3b9dd0
Compare
Instead of having to have files local in the filesystem (which is tricky to store securely), that are then copied to S3, which GitLab pulls from on launch, this makes it so GitLab secrets are stored in Secrets Manager, which GitLab pulls from on launch. This is a part 1 of (probably) 2 parts - this does not remove existing object, permissions or any associated config, to allow environments to keep on accessing the secrets as they were, so we don't have to migrate them all at once. Later parts will likely remove permissions and config. This is part of our move away from having to have any secrets locally on the filesystem.
michalc
force-pushed
the
feat/move-gitlab-secrets-to-secrets-manager
branch
from
a3b9dd0 to
6839f81
Compare
michalc
added a commit
to uktrade/data-workspace-gitlab
that referenced
this pull request
Jan 27, 2025
This is the corresponding PR to uktrade/data-workspace#223 - pulling GitLab secrets from Secrets Manager rather than S3.
michalc
added a commit
that referenced
this pull request
Jan 27, 2025
This follows up from #223 by making it possible to apply the terraform with GitLab enabled, but while not have GitLab secrets on the local filesystem.
michalc
added a commit
that referenced
this pull request
Jan 31, 2025
This follows up from #223 by making it possible to apply the terraform with GitLab enabled, but while not have GitLab secrets on the local filesystem.
michalc
added a commit
that referenced
this pull request
Jan 31, 2025
This follows up from #223 by making it possible to apply the terraform with GitLab enabled, but while not have GitLab secrets on the local filesystem.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Instead of having to have files local in the filesystem (which is tricky to store securely), that are then copied to S3, which GitLab pulls from on launch, this makes it so GitLab secrets are stored in Secrets Manager, which GitLab pulls from on launch.
This is a part 1 of (probably) 2 parts - this does not remove existing object, permissions or any associated config, to allow environments to keep on accessing the secrets as they were, so we don't have to migrate them all at once. Later parts will likely remove permissions and config.
This is part of our move away from having to have any secrets locally on the filesystem.