I have migrated a certificate from IBM Cloud Certificate Manager to Secrets Manager.
Now I have the same certificate in both Certificate Manager and Secrets Manager.
What should I do now to use the certificate from only Secrets Manager?
IBM Cloud Certificate Manager is integrated with some IBM Cloud services. The newer IBM Cloud Secrets Manager is a more general replacement. It includes support for certificates. There is a Certificate Manager to Secrets Manager migration guide.
From my experience, you should
set up notifications for expiring certificates
test if you can benefit from automated renewal / provisioning
check if your scenario is supported (could your app / service consume from Secrets Manager)
As stated, not all scenarios are supported right now and I use both Certificate Manager and Secrets Manager in parallel, for different sets of certificates and secrets.
Related
I want to deploy a web API on Google cloud and for test purposes I would just put the API key in the app.yaml file as an environment variable. Is this a security issue?
It's generally problematic to persist secrets to files. Even if the app.yaml were inaccessible from the runtime service, you'd still face challenges that it be exposed in build logs and if you inadvertently commit app.yaml to e.g. github.
For "testing", you can run generally run an App Engine locally. This isn't a perfect replica of the production service but it should be sufficient for testing.
A solution for managing secrets is e.g. Google's Secret Manager. SDKs (encouraged) and the underlying REST API (discouraged) are available.
I am wondering if it's possible to store credentials like passwords, tokens and keys safely in my GitLab project.
Currently there are a bunch of Java files with some passwords stored in it for testing purposes. However, I don't want to push this information on my repo due to security reasons. I tried using environment variables in the project, but they only seem to work for the .gitlab-ci.yml file.
My question is does anyone use a vault like Hashicorps or Blackbox to encrypt sensitive information?
Thanks
You can check out GitLab 12.9 (March 2020) which comes with:
HashiCorp Vault GitLab CI/CD Managed Application
GitLab wants to make it easy for users to have modern secrets management. We are now offering users the ability to install Vault within a Kubernetes cluster as part of the GitLab CI managed application process.
This will support the secure management of keys, tokens, and other secrets at the project level in a Helm chart installation.
See documentation and issue.
See also GitLab 13.4 (September 2020)
For Premium/Silver only:
Use HashiCorp Vault secrets in CI jobs
In GitLab 12.10, GitLab introduced functionality for GitLab Runner to fetch and inject secrets into CI jobs. GitLab is now expanding the JWT Vault Authentication method by building a new secrets syntax in the .gitlab-ci.yml file. This makes it easier for you to configure and use HashiCorp Vault with GitLab.
https://about.gitlab.com/images/13_4/vault_ci.png -- Use HashiCorp Vault secrets in CI jobs
See Documentation and Issue.
If you are not using environment variables in GitLab, then you are asking if it is possible to store secrets in GitLab. I have not done this myself, but I found this post about it:
https://embeddedartistry.com/blog/2018/03/15/safely-storing-secrets-in-git/
The author suggests three ways of storing secrets in git:
Blackbox
git-secret
git-crypt
The author was using BlackBox, but was going to migrate to git-crypt. From a quick look at it, git-crypt looks like something that I could use myself.
In IBM Bluemix you can create and be the member of multiple Organisations. How can I remove redundant organisations?
Deleting an existing organization is not possible at this time. This is limited to Bluemix Public. If you are a Bluemix Dedicated (or) Local user, you can delete existing organizations.
Please see : https://www.ng.bluemix.net/docs/admin/index.html#orgsandspaces
I think org delete must be manually done by bluemix support team. So open a ticket to get it done.
At this doc page
https://console.ng.bluemix.net/docs/admin/adminpublic.html#orgmng
It says:
Deleting an existing organization
Contact Bluemix registration and ID support to delete your
organization.
Note: Deleting operations cannot be reversed. You lose all your
applications and services that are associated with the organization.
You are able to delete organizations using the BX plug-in, also on Bluemix Public. Download and install the CF and BX plug-in using the link below
https://new-console.ng.bluemix.net/docs/cli/index.html#cli
Then use these commands below in the command line:
bx login
bx iam org-delete ORG_NAME [-f --all]
IBM Bluemix evolved over time from a Cloud Foundry public cloud offering over having Local and Dedicated editions to what is IBM Cloud today. There is Cloud Foundry and Cloud Foundry Enterprise Edition (CFEE). CFEE gives users access to the full administrator access and hence more options.
Thus, the answer depends on the context:
for CFEE there is a CLI command ibmcloud cfee org-delete
for the regular (old) public Cloud Foundry it is possible to delete spaces and users, but not orgs. This can be done through the CLI commands.
There is still a Bluemix Admin plugin for Bluemix Local and Bluemix Dedicated (Cloud Foundry for those environments) that allows to delete organizations. However, it does not work on IBM Cloud with Cloud Foundry.
I am automating deployment of a solution to Azure for CI purposes in powershell. I will be using WebDeploy to deploy websites and webjobs. I plan to create the CI user in Azure AD once for all environments, attach him to the subscription, download appropriate publishprofile file and put this file in the repository. Then use Import-AzurePublishSettingsFile while deployment is running on CI. Is this the optimal way to do it? Can I assume that the credentials stored in this file won't expire?
Since the .publishsettings file mechanism is no longer been worked on, you should create an Azure Active Directory Service Principal to grant access for your CI environment to Azure.
Import-AzurePublishSettingsFile is using a .publishsettings file that has been downloaded using the Get-AzurePublishSettingsFile. This command will create a certificate in your subscription.
You can login the Azure Classic Portal.
Click Settings > Management certificates, and search with the downloaded .publishsettings file name.
You will be able to get the expire date of the certificate. It's usually one year long. I am not sure if it's long enough for you.
If your need a longer term, I suggest you to upload your own certificate, and use certificate instead. For more information, see Upload an Azure Management API Management Certificate
For more detail about how to use the uploaded certificates, see Getting Started with Azure PowerShell Cmdlets–Subscription Management
We would like to integrate Gitlab with Okta, any advice on how to get started?
I met this question a few times while trying to get this working, posted the results on the following GitLab issue https://gitlab.com/gitlab-org/gitlab-ce/issues/14122#note_17669455
Yes, with GitLab 13.0 (May 2020), but only for Premium and more (so not free), and only for gitlab.com (not self-managed)
Okta SCIM Integration Application for GitLab.com
We now offer an Okta SCIM integration application for Gitlab.com groups!
When Okta SCIM is provisioned for a GitLab group, membership of that group is synchronized between GitLab and Okta. This reduces group administrator time spent to onboard and offboard users.
See documentation and issue.
Update 2023: GitLab 15.8 (January 2023) add support for self-managed GitLab instances as well! (still premium+ only).
SCIM support for self-managed GitLab
Self-managed GitLab now supports the open standard System for Cross-domain Identity Management (SCIM), which allows you to automatically:
Create users.
Remove users by deactivating their SCIM identities.
Previously, this was only available for GitLab.com.
SCIM enables GitLab administrators to completely automate their user lifecycle management.
See Documentation and Issue.