We have in Bluemix (CF) 1 org and 2 spaces: DEV and PROD.
For DEV developers have full access. For PROD developers assumed to have restricted access.
I read CF documentation about roles, but it did not answer my question fully. I understand that we can do for developers either
no access at all to PROD scpace (e.g. minimal scope is "space"), or
make developers read-only access to PROD (but they can read everything).
My question - is there any way to restrict access in the middle of these 2 approaches. For example - hide from developers pieces of sensitive information (passwords) in PROD (we can put them in the environment variables), and have developers read-write access to the rest of PROD space? Because of lack of skilled resources, developers will have to manage PROD space, but possibly without accessing sensitive information (e.g. passwords)
If the only bit of information you need to hide from your developers is those passwords in the app environment variables then you could take these out and store them externally in something like the Key Protect Service
The App then calls out to Key Protect, retrieves the passwords and connects to whatever required those passwords.
Obviously the developers can still get access to them if they try, since they can access the app but at least it will reduce the footprint.
We implemented it this way:
1) Developers initially configured PROD space environment.
2) Developers were removed from PROD space, and all other works are done by Org owner. Thus developers connot see PROD space at all (for example in tool chain it just hidden), and deployment and configuring is done by Org owner from now on.
Related
I have signed up my organization to a GitHub Teams free plan, and we are considering pushing our code to private repositories on GitHub. Our projects consist of decades old legacy code and there are lots of hard-coded credentials (not only in the code, but also in comments) for various servers and databases.
I do not want to make my team change all this code to store credentials in config files, I am not 100% sure our various tech stacks support this. It would also be very time consuming, and there is no guarantee we can find every single reference of credentials. I’m just wondering if it is safe to push the code with all these credentials even if the repositories we create are not public?
Storing your code on GitHub is no less secure than storing it anywhere else. For example, GitHub generally takes significant effort to secure repositories, and staff are not permitted to look at the contents of private repositories without the consent of the repository owner. Pushing this code to GitHub will not intrinsically expose it any more than storing it on any other server.
However, having said that, storing credentials in your repository is a security problem regardless of where you host that code. It is easy for a repository to accidentally leak for many reasons, due to server misconfiguration, laptop theft, or various other situations. You would be well served to put at least a modicum of effort into using a more secure practice for storing credentials, if for no other reason than that you will have them stored in a single, secure place where you can find them all. For example, rotating credentials is much easier when they all live in a tool like Vault and you can easily rotate a compromised credential across all systems.
So, in general, what you are doing is not very secure, but using or not using GitHub will not change that.
Using Github Enterprise, I have a service/bot account where I'd like to generate a number of Personal Access tokens and provide to a number of teams.
Is there any limit in how many Personal Access Tokens can be generated per user?
As far as I'm aware, there is no limit, but if you want to be sure, you should ask either the GitHub support team or on the GitHub community forums.
GitHub itself has such a bot account and PATs are frequently used there, but do be aware that the UI may be a little (or, depending on how many tokens you issue, very) slow, since it isn't designed for people to have huge numbers of PATs.
You may find it more desirable to use deploy keys if you're accessing a repo, since these have a smaller scope (one repository) and won't have the UI problems mentioned above, but of course that won't work for the API.
We're having a lot of developers just sign up for Azure DevOps, create their own Org, and use the five free licenses. This creates big problems if they were to leave. Is there a way to stop this or at least be notified when this happens?
There's no way to prevent it that I'm aware of. You should definitely ensure that everyone is using organization accounts ("work or school" as opposed to "personal" accounts) and that your Azure DevOps organization is backed by Azure Active Directory, so that at the very least you can retain access to any accounts created by others.
However, there's nothing wrong with creating an account to use as a sandbox. In fact, it's very common, as it can be useful to have an unrestricted place to try out features.
If people are creating additional accounts and then using them for real work on an ongoing basis, it sounds like you have a "people problem" in your organization that needs to be addressed, not a tooling problem.
Are people not being given appropriate access to the place they should be working in a timely fashion? This points to a problem with on-boarding.
Are people unaware of where they should be working? This is a training/documentation problem.
How are they working in a personal account without other collaborators (such as managers, teammates, or business users who are managing the backlog) being aware of it? If their manager/technical lead is aware of it, why is their manager/technical lead not redirecting them to an appropriate location? This represents a communication problem (specifically, lack of communication).
Is there any GitHub SSH Deploy key limit. Let's say I would need 2000 or even 4000 deploy keys added to the git repository. Is that possible or will I hit the limit at some point?
The reason for this is that we would have 4000 devices that would need to be provisioned. And we want to have control which device can access repository and if necessary disable it. Another option is indeed access tokens, but as far I understand they are linked to the account, not repository.
https://help.github.com/articles/git-automation-with-oauth-tokens/
And that would also mean that we would need to manage the permissions separately to which repository they have access to.
First of all, why would you need up to 4000 deploy keys? This is a pretty large number and I think you should explain why you need such a large amount of deploy keys for one single repository.
However: I contacted the GitHub support, after I couldn't find anything about this in the GitHub documentation and got the following response:
I don't believe we have a fixed limit on SSH keys or deploy keys
although as the settings pages weren't designed with this sort of
usage in mind, I think it would be rather difficult to manage.
When someone needs to control access to such a large number of
machines, we'd usually recommend creating personal access
tokens instead,
as these can be automated and will provide similar access. If
the huge number of keys was necessary and causing problems, we'd do
our best to help.
I realize the general compartmentalization of apps & services into spaces so you can control access and such.
But I am not clear on why there is also the concept of organization? Are usage charges done per org? Or is it just a way to organize spaces?
Organizations are the concept to manage resources and, well, organize work. The Cloud Foundry docs say about an organization:
An org is a development account that an individual or multiple
collaborators can own and use. All collaborators access an org with
user accounts. Collaborators in an org share a resource quota plan,
applications, services availability, and custom domains.
As you said, spaces are used to deploy resources and to control access. Adding another org would make sense to introduce another department, project or maybe even a business unit to a Cloud Foundry instance like the IBM Cloud with Bluemix. Who is accountable (for the deployed resources)? How are projects and teams organized?
Yes - an organization helps segregate different development efforts, similar to the way a space works. However, when you look at your usage and your bill you can see it broken out by organization. It's one of the reasons I suggest doing different organizations for different cost centers in an organization - so you can do chargebacks. See https://developer.ibm.com/dwblog/2017/ibm-cloud-bluemix-watson-new-customers/...
In Cloud Foundry, Organizations are top level management which consists of multiple spaces. Spaces is like specific team or you can consider as different environments like development, testing, pre-prod or prod. There are multiple roles both in Organization and Space.
For Organization, there are Org Manager and Org Auditor.
Org Manager will look invite users to organization, view quotas and assign quotas to spaces. Org Auditor can check how many users in an org, spaces, quotas details but they can't edit or make change in an organization.
I recommend to have a look at this link https://docs.cloudfoundry.org/concepts/roles.html#orgs