CODEWITHSUNDEEP
gitdeploymentcontinuous-integration
Sam
Sam

Reputation: 124

Where to store private keys for a continuous integration (CI) deployment?

I'm building a continuous integration deployment that is based off a private git repository. My project contains an un-versioned PK file in the resources directory. This works fine when I deploy manually, I ensure a copy of the private key is on the path from whatever workstation.

Now that I'm deploying from the repository, I am curious where to store the key. This is a private repo, I suppose I could just version the PK but I'd rather not if there is an alternative.

Any tips or tricks?

UPDATE: Sorry for the vagueness, the PK is a service account used with Google APIs. So it's something that must be provided at runtime to the Java API library. For example:

public void startGoogleDrive() {
    HttpTransport httpTransport = new NetHttpTransport();
    JacksonFactory jsonFactory = new JacksonFactory();
    GoogleCredential credential = new GoogleCredential.Builder()
            .setTransport(httpTransport)
            .setJsonFactory(jsonFactory)
            .setServiceAccountId(SERVICE_ACCOUNT_EMAIL)
            .setServiceAccountScopes(Arrays.asList(DriveScopes.DRIVE))
            .setServiceAccountUser(userEmail)
            .setServiceAccountPrivateKeyFromP12File(
                    new java.io.File(SERVICE_ACCOUNT_PKCS12_FILE_PATH)) // <- private key file
            .build();
}

Upvotes: 2

Views: 1249

Answers (1)

Ed I
Ed I

Reputation: 7358

Yes, it's almost always a bad idea to keep credentials or otherwise sensitive data in your Git repositories.

The only good practice of which I am aware for versioning things such as private keys would be to put them in the private repository of a configuration management policy, such as CFEngine, Puppet, Ansible, Chef or Salt. When the configuration management system daemon runs it can create or update the key from the repository. Then again, if done haphazardly, even this can lead to keys that can be abused.

I would personally not keep that key in the source repository for the project. You might yet find a case when someone needs to see the code but not have access to the key. The key should ideally be deployed individually to the application server, either manually or via a configuration management system.

Upvotes: 3

Related Questions